Module: MIME

About this module

The MIME module performs decoding of mailmessages, and also serverpush HTTP documents delivered as mulitpart/x-mixed-replace content

Supported protocols:

Interface overview and API documentation

API documentation generated by Doxygen contains all necessary information for the external APIs.

Decoding of email

The client configures a URL as a opera-email type URL, or loads a URL with the content-type "application/mime", the content is then passed through a Cache_Storage derived element that manages the process of pushing the content through a MIME_Decoder, and extracting the viewable HTML content into the publicly available Cache_Storage object in the object. It also manages the locking mechanism for the attachment URLs.

Decoding of HTTP serverpush streams

When a server specifies a content-type of "application/x-mixed-replace" or "application/mixed" the content is boken up into separate bodyparts that are presented to the user in a sequence. Each new bodypart (after the first) is preceded by a MSG_MULTIPART_RELOAD message that indicates that the document must complete rendering the document, as when the next header loaded message arrives it should start displaying the next bodypart. Message handling is otherwise just like normal URL loading.

A special tweak (TWEAK_MIME_ALLOW_MULTIPART_CACHE_FILL) can be used to change the handling of "application/mixed" into a cache filling mechanism.

The functionality is implemented as a StreamCache_Storage derived class, and calls on the list of bodyparts to create datadescriptors. It is not possible to get more than one datadescriptor for a bodypart.

Implementation description

API documentation generated by Doxygen contains information about the internal organization of the module.

Footprint

The module is moderately large. Various features can be enabled or disabled, either thorugh feature defines or specific defines.

Due to the requirements from various modules (including the url module) and platforms it is very difficult to reduce the footprint

Dynamic memory use and OOM handling

OOM policies

Most of internal module functions handles OOM by LEAVING, these LEAVES are TRAPed internally, and handled locally by signaling the condition, and ending the load process

Who handles OOM?

In the case of the internal functions these usually aborts their operation with an error message, and a raised status flag, which must be handled either by the caller, or the document.

Flow

Most of the actions of the module is triggered by external events. Information about problems is indicated by posting of error codes, and ending the operation

Decoding is triggered by the URL_DataStorage object pushing data into the top object, and this data is then pushed into subsidiary documents. If there is a failure the class will take necessary action, including ending the decoding operation, and return.

Heap memory usage

The module stores all data in URLs, these can either store the information to disk, or in RAM, depending on specifications by the datasource caller. There is also several temporary buffers in use during decoding, these can be as large as the buffersize that is being input by the caller.

Stack memory usage

Usually large objects are allocated on the heap. In some cases sizeable objects are placed on the stack but only for shorter periods.

In most cases stack consumption should be less than 300 bytes.

Static memory usage

The module is using 4 const arrays consisiting of up to 50 KeywordIndex objext (about 400 bytes, plus strings no longer than 20 bytes, totaling less than 1500 bytes). These arrays are usually generated at compiletime, but may be allocated and initialized at startup on some platforms

No other permanent storage is kept; all longlived data storage is maintained by the URL, and can be removed by unloading the URL.

Caching and freeing memory

All longlived data storage is maintained by the URL, and can be removed by unloading the URL.

Freeing memory on exit

Normal cache storage shutdown will unload the URLs and the stored documents. Owners of unique URLs must destory the URL objects they own.

On some platforms allocated Const arrays will be deleted on shutdown

Temp buffers

Alle three memeory manager tempprary buffers are used for some internal operations

Memory tuning

At present there are no opportunities to tune memory use.

Tests

Selftests, but they do not check memory usage.

Coverage

MIME coverage can be tested loading various complex MHTML messages or emails with attachments, serverpush coverage can be loading a stream of webpages or images, e.g. this on t.

Design choices

The code processes buffers of data and passes these on to the next stage of the process. All longterm storage is managed by Cache_Storage elements or URLs and therefore follow the same patterns as these,

Improvements

At present, no improvments are planned.