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: New Modules
Date Sun, 12 Apr 2009 11:58:12 GMT
On Thu, Apr 9, 2009 at 7:26 PM, Robert Burrell Donkin
<robertburrelldonkin@gmail.com> wrote:
> i plan to take a look at
> https://issues.apache.org/jira/browse/MIME4J-120 (adding a templating
> module)

Okay.. I guess if you want to e.g. create an Atom from a message you
are interested in the message's header fields like subject, sender and
recipient and maybe only a preview of the content, right?

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

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

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.


View raw message