On Sun, Apr 12, 2009 at 12:58 PM, Markus Wiederkehr <[email protected]> wrote: > 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?
sounds like a typical use case >> 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. <snip> >> 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. apologies for the confusion - the templating module is an independent idea. i'll start another thread for that. - robert
