james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Wiederkehr <markus.wiederk...@gmail.com>
Subject Re: Alternative Storage Modules [WAS Re: New Modules]
Date Sat, 18 Apr 2009 19:00:37 GMT
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.

> 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 arbitrary
documents along with meta information of all kinds (e.g. headers,
possibly decoded as well as raw). I think it should be possible to
specify sub-documents (e.g. parts of a message).

Just a thought..

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