On Sat, Apr 18, 2009 at 8:00 PM, Markus Wiederkehr <[email protected]> wrote: > On Thu, Apr 16, 2009 at 7:41 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: >> >> <snip> >> >>>> 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. >> >> there are downstream use cases involving spooling to disc that i've >> been wondering whether mime4j could be used for. spooling requires >> reliable streaming to disc. this would require header storage as well >> as envelope attributes. >> >>>> 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. >> >> cool >> >>>> 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. >> >> yep > > I'm not sure where you want to go with this. Storage/StorageProvider > was designed to store a stream of bytes, no more, no less. So > StorageProvider has no concept of a MIME message or message headers.. > And frankly I would prefer it if it stayed that way.
yes, StorageProvider just stores streams. so, it's not a suitable extension point. >> this is also true of the downstream storage use cases. for example, >> quick access is required to the parts of compound headers for IMAP. > > Maybe it's an overkill but have you looked at Apache Jackrabbit? I'm > not very familiar with it but it seems to be able to store arbitrarhat y > documents along with meta information of all kinds (e.g. headers, > possibly decoded as well as raw). I think it should be possible tooors > specify sub-documents (e.g. parts of a message). the DOMs in both Mime4J and JavaMail both suffer from the disadvantage that they internally manage their own storage in a fashion that is hard to subclass. so, when you have a document that has already committed to storage, it has to be reparsed before the DOM is available. similarly, when spooling a document on entry to the system, it has to be parsed then stored. this is inefficient. a single DOM interface agnostic of storage solution would be useful downstream. JavaMail lacks suitable extension points. Message - and the associated hooks - would probably need some rethinking and suitable extension points would need to be identified and added, but i think that the effort would be worthwhile. - robert
