Maybe we can do this way: We can have processor that works on the raw streams and processor that works on a structured mail.
THe input is a raw stream, and we keep the stream until some processor require parsed data access. When this happens we convert the raw message to parsed message. If a processor require a stream from a parsed message then the stream is regenerated from the structure. Maybe we simply have to support both raw-stream and parsed-message objects in the JCR and then have tools to convert from one to another on top of this JCR. If the application wants to keep both representation it could store 2 different objects and manually manage the relationship (and their synchronization). WDYT? Stefano Jukka Zitting ha scritto: > Hi, > > On 5/17/07, robert burrell donkin <[EMAIL PROTECTED]> wrote: >> On 5/16/07, Jukka Zitting <[EMAIL PROTECTED]> wrote: >> > One possible approach, at the expense of storing potentially redundant >> > duplicate data, is that the original message source is stored as a >> > verbatim binary stream and the message content is automatically >> > "exploded" when the first client that actually needs to parse the >> > message. >> >> i really like this idea :-) > > There's one major caveat with this approach: redundant information and > the performance cost of maintaining that. > > Maintaining updates in the raw message stream is in some (many?) cases > much more expensive than in a fully parsed representation. Consider > for example a mailet that wants to modify a subject line or add a > footer to all messages. Such operations would require that we update > the original message content as well as the individual header property > or body part in question. Updating the raw message source can in such > case easily take an order of magnitude more time than updating the > parsed representation. > > Note that I believe that it is possible to parse an incoming message > into a JCR node tree and recreate it back into a byte stream in the > same O(n) time and O(1) memory as is required to stream the raw > message source to a traditional spool file. > > Perhaps we should have two modes for the JCR mail repository > implementation: one for pure relaying and one for more complex > processing. The former satisfies the relaying requirements of the SMTP > spec, while the latter is optimized for message transformations and > complex access patterns like in IMAP or webmail clients. > > BR, > > Jukka Zitting --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
