On Dec 1, 2007 1:24 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin wrote: > > > Noel J. Bergman 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. > > Why?
IMAP is too tightly coupled ATM > > the mailbox API is full of cruft but most of it will be gone in due > course. > > As I've said, the mailbox API didn't exist until trunk, has no value outside > of trunk development, and so you should feel free to do whatever you want to > it. Including a wholesale rewrite. > > > > 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. > > Do you want to discuss an efficient store for decomposed MIME messages, and > a MIME stream interface that would provide easy and efficient access to them > on demand? if discussion is necessary - i'd be as happy for you to just write 'em ;-) > We could have both JavaMail and stream interfaces built on top > of the store. that's the way the current IMAP is heading. (well actually, the IMAP implementation is heading away from using JavaMail at all.) the streaming needs to be support nio. (batched streaming ByteBuffers rather than bio.) IMAP needs efficient access to meta-data about each MIME part (octet count as well as MIME headers etc) and nio batched streaming for the content > > i agree with principle. one of the major issues with the current > > mailbox API is the wasteful pushing of bits needlessly around. > > I'd refer to it as the experimental mailbox API, since there is nothing > "current" about it. In any event, moving data is an issue in the current > stable code, too, unless one uses dbfile. current as in codestream <snip> > > 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. > > Mailboxes have their own attributes, and are not just collections of > messages. the major heavy lifting is at the message meta-data level each mailboxes is fundementally a collection of message-level meta-data. most of the rest is to either caching message level data or issues of namespacing. which is another major issue ATM > > > 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? > > Not necessarily, no, unless you're being loser with the terminology than I > would be. i'm running pretty general and loose ATM i'm just trying to qualify the difference between a JAMES attribute, the SMTP envelope and a SEEN flag (as used by IMAP or POP3) > > is a conceptual division needed between this meta-data and the > > meta-data used by POP3 or IMAP to record information about mailboxes? > > There may be a physical division, much less a conceptual one. yes but if it's a physical difference does it need to be embedded in the design of the APIs? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
