On Thu, Apr 9, 2009 at 7:26 PM, Robert Burrell Donkin <[email protected]> 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. Markus
