Differences between revisions 6 and 7
Revision 6 as of 2007-11-06 13:48:47
Size: 2625
Comment: Class diagram for factory structure
Revision 7 as of 2009-09-20 22:58:16
Size: 2637
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 37: Line 37:
Here's a class diagram for the current interfaces: http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/mailboxapi/current20071102.png Here's a class diagram for the current interfaces: {{http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/mailboxapi/current20071102.png}}
Line 45: Line 45:
Here's a strawman for MIME Structure: http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/mailboxapi/structure20071104.png Here's a strawman for MIME Structure: {{http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/mailboxapi/structure20071104.png}}
Line 53: Line 53:
Here's a class diagram for the current factory interfaces which create managers and mailboxes: http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/mailboxapi/factories.png Here's a class diagram for the current factory interfaces which create managers and mailboxes: {{http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/mailboxapi/factories.png}}

Backend Mailbox API Feature Requirements

  • This list of features we need to support, or want to support by the backend API.
  • POP3 needs
    • 'username+password' -> 'inbox' mapping,

    • listing of the content of inbox, with subject only (?)
    • getting the content of an email by it's id
    • deleting messages from the inbox
  • SMTP needs
    • 'email address' -> 'mailbox' mapping

    • putting an email into the mailbox
    • SMTP compliance we should make sure that a message is not normalized or "fixed" before it is relayed
  • NNTP needs
    • ???? I don't know :)

  • Internal James API needs (spooling, fetchmail, etc):
    • handling various 'spool' 'mailbox'es, adding and removing items to them.
  • IMAP needs:
    • handle mail specific flags (Answered, Deleted, Draft, Flagged, Recent, Seen...)
    • ability to search by various header parameters (From, Subject...), flags
    • handle mailbox hierarchy per user (this would be nice for JSieve also, as I know)
    • shared/readonly mailboxes (this is optional)
    • custom properties for mail, the MIME structure is important, but some useful imap extensions needs others, for example CONDSTORE/QRESYNC as I remember needs a 'transaction number'.
  • Other features, which we want to consider comes from the deployment scenarios :
    • db only backend
    • db for the metadata, file system for the data, in maildir/mbox/custom format
    • db less backend, pure file system
    • mixed backend (for example, the user mailbox are in a db, the shared, read only mailboxes are on the disk.
    • jcr backend
    • james servers in front of the same backend (probably db-only, or jcr)


Current API

Here's a class diagram for the current interfaces: http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/mailboxapi/current20071102.png

Seems excessively complex


MIME Structure Strawman

Here's a strawman for MIME Structure: http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/mailboxapi/structure20071104.png

Probably something simple should be enough - some recursion, a couple of interfaces plus access to mail headers, MIME meta-data and Content should be enough.


Factories, Factories and more Factories

Here's a class diagram for the current factory interfaces which create managers and mailboxes: http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/mailboxapi/factories.png

Again, seems excessively complex. IMHO it would be better to have a canonical mechanism for each function. Concise APIs are easier to learn and easier to implement.

BackendMailboxAPI (last edited 2009-09-20 22:58:16 by localhost)