mstor
Home :: Features :: Documentation :: News :: Support :: Download :: License
Features »
mstor includes the following notable features:
  • Mbox-compatible email storage
  • Support for additional metadata not inherently supported by the mbox format
  • Designed for handling large mailboxes without significant performance or memory degradation
Mbox-compatible »
Leveraging the wide-spread use of the unofficial mbox format, mstor may also be used to access email in traditional mbox folders. The modular nature of mstor's design also means that additional storage formats may also be included in later versions.

mstor now provides folders that support both messages and subfolders. In order to maintain greater compatibility with other mbox implementations mstor uses a filesystem structure similar to that used by Mozilla Thunderbird.

Anatomy of mstor 

An example of an mstor store filesystem structure is as follows:

MyStore/                 - default folder (holds folders only)

    Inbox                - the mbox file for the Inbox folder
                         - (holds folders and messages)

    Inbox.emf            - the metadata file for the Inbox folder

    Inbox.sbd/           - the directory that contains subfolders
                         - of the Inbox folder

        Newsletters      - the mbox file for the Newsletters subfolder

        Newsletters.emf  - the metadata file for the Newsletters subfolder
Metadata »
An inherent problem with many of the local store providers available today is that they don't support all the possible metadata that is accessible via the JavaMail API (e.g. Received Date/Flags). Those that do support these features tend to use message headers to store this additional metadata. mstor aims to leave messages "untainted" as it were, and therefore stores additional metadata in a separate XML file (one for each folder). One of the benefits of using a separate data format is that a much richer set of metadata may be collected.
Performance »
Although there are a number of local store providers available, they all seem to have the same performance deficiences when accessing large mailboxes. Whilst speed is generally not an issue when using these providers, a major concern is the memory usage - generally a result of blindy loading the entire mailbox into memory. mstor aims to provide more control over the performance vs. memory usage equation by combining smarter caching techniques with efficient data access methods (based on the Java New I/O API).