On Nov 30, 2007 10:25 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin wrote: > > > > > the current table structure [in trunk] is inefficient. > > > > opinions? > > As I said, toss and reboot.
today, this implies tossing and rebooting IMAP. i've starting to make real progress on fixing this mess and am closing in on a full IMAP implementation. the mailbox API is full of cruft but most of it will be gone in due course. > We need to change the data storage scheme. As a strawman, we should > separate spool, mailbox and message store. > > The message store is simple: the message. Once a message is in here, it > need not be moved, it is just referenced. +1 IMAP (and other reading-centric protocol) requires MIME decomposition. each part of a MIME message needs to be available via a separate reference. efficient access to the meta-data for each part is necessary. this is very different from POP3 which AIUI requires access to the raw message. but i agree with principle. one of the major issues with the current mailbox API is the wasteful pushing of bits needlessly around. > The mailbox should serve the needs of both POP3 and IMAP. It contains no > actual message content, delegating to the message store. there's no real need to push the bytes in a mail around. protocols just add layers of meta-data on top of the aboriginal content. a mailbox can easily be implemented just by a meta-data layer. > Spool contains the spool records. Conceptually, the mail object, which > means SMTP envelope, spool state, message meta-data, etc. isn't this just message meta-data? is a conceptual division needed between this meta-data and the meta-data used by POP3 or IMAP to record information about mailboxes? > Personally, since I do not really care that much about IMAP (although once > we have it, I would like to see, and possibly contribute to, calendar and > contacts beind added), I am concerned with the message store and spool; a > simple mailbox sufficient for POP3 is fine by me. But you'll want more than > that, and that's fine. > > I also want a transactional store, so that we can ensure that once a message > enters a processor, the processor either completes, or any changes are > rolled back. Having all of the stores on top of the same underlying > relational database means not requiring XA. transactions are a popular requirement :-) - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
