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 Templating Module [WAS Re: New Modules]
Date Sat, 18 Apr 2009 19:02:04 GMT
On Thu, Apr 16, 2009 at 7:36 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:
>>> 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?


View raw message