james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Generic Mailbox API [was: IMAP development]
Date Mon, 18 Sep 2006 09:50:48 GMT
Hi guys,

When designing the mail API pop3 and imap implementations, very
naturally the discussion comes up how to provide the different
capabilities in the right way. I came onto it because Joachim wrote
"ImapMailbox extends Pop3Mailbox ... I don't like that." Maybe I
stretched his original statement a little bit ;-) but that's what I
read into it.

Instead of following the canonical approach of specialization
("extends") I would rather follow a top-down approach: building a
"generic mailbox API" offering all the features we currently want to
have. Initially, it would have all POP3 features and could converge
against full IMAP feature set over time.

The protocol implementations would only adopt those features they have
to provide.
It would reduce code duplication from start.

What I'd particulary like about it, we could also provide a service
interface which enables specialized James client applications to
access mail by circumventing POP3/IMAP.

This would enable us to add features which are not required by common
APIs, like google-like index searches, custom mail flagging,
clustering support and others.

This is not a completely new idea, but probably the time to put it on
the plate again.

Please note, this is not a proposal about funky new features, but
about having the architectural grounds to build IMAP and all what may
or may not come after that.

WDYT?

  Bernd

On 9/18/06, Joachim Draeger <jdraeger@gmx.de> wrote:
> Stefano Bagnara schrieb:
>
> At the moment I don't think it makes sense to provide an additional
> pop3-specific Pop3Mailbox interface that can only be queried by msn and only can
> provide message, msn, size and key. And msn, size and key should be bundled in
> one result type, not to have to make 3 queries or determine the size by fetching
> the message object. (which is probably expensive)
> So you would need a Pop3MessageResult and a ImapMessageResult (which extends
> Pop3MessageResult).
> ImapMailbox extends Pop3Mailbox.
> What should ImapMailbox provide? A Pop3MessageResult that can be casted to an
> ImapMessageResult? I don't like that.
> Provide getPop3MessageResult and getImapMessageResult?
>
> > POP3 needs:
> > - read a full message
> > - read N lines or the full header
> > - get the list of message keys and their sizes
> > - get a count of the total number of messages (and possibly their total
> > size)
> > - delete a message
> >
> > Our repository currenlty is not so good for the "key size" list and for
> > the "total size" result.
>
> ... and that requires operations that could be quite expensive.
>
> > Is there a similar "analysis" done for Imap? I know that the imap
> > protocol itself provides a lot of features, but I also wonder if the
> > imap clients uses all of IMAP commands in all the ways or if we have a
> > subset of used "commands with specific parameters".
>
> Well, imap makes no sense without flags and uids. Well, maybe the internalDate
> could be faked to the date in the header...
>

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


Mime
View raw message