The MIME module performs decoding of mailmessages, and also serverpush HTTP documents delivered as mulitpart/x-mixed-replace content
Supported protocols:
API documentation generated by Doxygen contains all necessary information for the external APIs.
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.
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.
API documentation generated by Doxygen contains information about the internal organization of the module.
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
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
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.
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.
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.
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.>
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.
All longlived data storage is maintained by the URL, and can be removed by unloading the URL.
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
Alle three memeory manager tempprary buffers are used for some internal operations
At present there are no opportunities to tune memory use.
Selftests, but they do not check memory usage.
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.
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,
At present, no improvments are planned.