On Sat, Apr 18, 2009 at 8:02 PM, Markus Wiederkehr <[email protected]> wrote: > On Thu, Apr 16, 2009 at 7:36 PM, Robert Burrell Donkin > <[email protected]> wrote: >> 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. > > So a templating module could be written without modifying the existing > code base? As a separate module or even a separate project?
it's quite possible that - as a new use case - some improvements to the DOM may well emerge as part of the process but the templating would just be an extension module - robert
