james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Questions on the Mail and MailRepository interfaces
Date Wed, 16 May 2007 13:38:48 GMT
Jukka Zitting ha scritto:
> A message consists of a envelope and the contained message. In JCR
> this is represented as the james:mail subclass of the standard nt:file
> node type (see http://wiki.apache.org/jackrabbit/nt%3afile):
>    [james:mail] > nt:file
>    - james:state (STRING)
>    - james:error (STRING)
>    - james:sender (STRING)
>    - james:recipients (STRING) multiple
>    - james:remotehost (STRING)
>    - james:remoteaddr (STRING)
>    - jamesattr:* (UNDEFINED)

If we move to MessageRepository (JCR based) + EnvelopeRepository (JMS
based) model then we don't need the state, error, sender, recipients,
remotehost, remoteaddr, attributes stuff in the message repository.
Instead we may need some IMAP stuff in the MessageRepository (for the
IMAP stuff you may be interested in this document written by Joachim
months ago: http://www.joachim-draeger.de/JamesImap/drafts.html )

> [..]
> Normal mail messages are represented as a tree of MIME entities or
> parts. Each entity is individually referenceable (for easy linking and
> quick access) and contains associated the mail headers as string
> attributes:
> [...]
> I'm still undecided on how deep I should go in pre-parsing the message
> contents. For example should I parse Date headers and store them as
> JCR DATE properties to enable efficient date-based queries? Another
> complex question is how to best handle encryption and digital
> signature mechanisms like S/MIME...

I'm not sure at all that the backend should be aware of the
content/structure of the message.

The MOST IMPORTANT thing at all is that if I store a message and I later
retrieve it every single space, every single header, everything is
exactly as I wrote it. Even if it was malformed.

To achieve performance we'll probably have to avoid parsing the mime
structure at all: we don't need this for most SMTP/POP3 operations. Some
IMAP operation needs this, but this should probably done on demand and
not when writing the message to the repository.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message