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 Alternative Storage Modules [WAS Re: New Modules]
Date Thu, 16 Apr 2009 17:41:47 GMT
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:


>> 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.


>> 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.


this is also true of the downstream storage use cases. for example,
quick access is required to the parts of compound headers for IMAP.

> And do you really need a separate storage for that? Wouldn't it be
> sufficient to write a ContentHandler that parses the header fields and
> reads only a few lines of the actual content and then create a
> Velocity context from those parsed objects. I guess it wouldn't even
> be necessary to recurse into inner parts of the message.

sorry for the confusion: i shouldn't have lumped together two
independent issues. if mime4j standardised storage for mime documents
then this would improve interoperatbility between downstream users
which need persistence storage for mime documents.

- robert

View raw message