james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <robertburrelldon...@gmail.com>
Subject Re: Alternative Storage Modules [WAS Re: New Modules]
Date Sun, 19 Apr 2009 14:01:36 GMT
On Sat, Apr 18, 2009 at 8:00 PM, Markus Wiederkehr
<markus.wiederkehr@gmail.com> wrote:
> On Thu, Apr 16, 2009 at 7:41 PM, Robert Burrell Donkin
> <robertburrelldonkin@gmail.com> wrote:
>> On Sun, Apr 12, 2009 at 12:58 PM, Markus Wiederkehr
>> <markus.wiederkehr@gmail.com> wrote:
>>> On Thu, Apr 9, 2009 at 7:26 PM, Robert Burrell Donkin
>>> <robertburrelldonkin@gmail.com> wrote:
>> <snip>
>>>> i'd also like to add modules to support parsing into stores other than
>>>> file, in particular JCR and OpenJPA. the initial use case would be
>>>> upstream in server and imap but my hope is that they might develop
>>>> into standard representations.
>>> Implementing a StorageProvider that uses JPA should not be a problem.
>>> But please note that at the moment only the message's text and binary
>>> parts are written to storage. The header fields are kept in memory.
>> there are downstream use cases involving spooling to disc that i've
>> been wondering whether mime4j could be used for. spooling requires
>> reliable streaming to disc. this would require header storage as well
>> as envelope attributes.
>>>> the idea would be to allow the DOMish interface we already have to be
>>>> used interchangable of the store type.
>>> That should already be possible. MessageBuilder has a setter to
>>> specify a StorageProvider or something like that; I don't have the
>>> source code at hand right now.
>> cool
>>>> i'm being intentionally vague
>>>> so that everyone has a chance to comment before i start creating JIRAs
>>>> etc.
>>> Like I said I guess you are interested in the header fields and herein
>>> lies the problem. For example in case of the subject field you are
>>> probably interested in the decoded subject and not the raw encoded
>>> words. Same for sender and recipient addresses. So it wouldn't do to
>>> fill the Velocity context with raw header fields. The header fields
>>> would already have to be understood and parsed.
>> yep
> I'm not sure where you want to go with this. Storage/StorageProvider
> was designed to store a stream of bytes, no more, no less. So
> StorageProvider has no concept of a MIME message or message headers..
> And frankly I would prefer it if it stayed that way.

yes, StorageProvider just stores streams. so, it's not a suitable
extension point.

>> this is also true of the downstream storage use cases. for example,
>> quick access is required to the parts of compound headers for IMAP.
> Maybe it's an overkill but have you looked at Apache Jackrabbit? I'm
> not very familiar with it but it seems to be able to store arbitrarhat y
> documents along with meta information of all kinds (e.g. headers,
> possibly decoded as well as raw). I think it should be possible tooors
> specify sub-documents (e.g. parts of a message).

the DOMs in both Mime4J and JavaMail both suffer from the disadvantage
that they internally manage their own storage in a fashion that is
hard to subclass. so, when you have a document that has already
committed to storage, it has to be reparsed before the DOM is
available. similarly, when spooling a document on entry to the system,
it has to be parsed then stored. this is inefficient.

a single DOM interface agnostic of storage solution would be useful
downstream. JavaMail lacks suitable extension points. Message - and
the associated hooks - would probably need some rethinking and
suitable extension points would need to be identified and added, but i
think that the effort would be worthwhile.

- robert

View raw message