Bernd Fondermann schrieb:
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.
What I wanted to say it that I don't like adding a method for every single query
and result type combination. And even for POP3 there are more then on possible
result combinations.
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.
With GeneralMessageSet, MessageResult, Mailbox.get(Possible)MessageResultTypes()
and Mailbox.get(Possible)MessageSetTypes() I tried to provide a generic access.
Do you have something different in mind?
The protocol implementations would only adopt those features they have
to provide.
It would reduce code duplication from start.
Pop3, imap, and JavaMail have IMO more common requirements then differences.
E.g. session-stable message numbering is a very complicated thing but needed by
all 3.
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.
Yes I really do like that idea, too. That's why I always keep JavaMail in mind.
Current proposal is feature-compatible with JavaMail, so it is possible to write
a wrapper and access mail circumventing POP3/IMAP without even being James
specialized.
(NO it is NOT JavaMail centric. JavaMail is POP3 and IMAP centric so there is a
big intersection)
It would even be desirable to put out Mailbox API with backends as a by-product
to broaden user-base.
Another point is that it would offer more possibilities for mailets etc.
Spam could be moved to a junk folder, jSieve can get into action and so on.
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?
Could you give an example? I fear I didn't completely understand what you are
proposing...
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
