Re: [imap5] Designing a new replacement protocol for IMAP

[Bron Gondwana <[e-mail]>]

On Thu, Feb 16, 2012, at 11:30 AM, Tony Finch wrote:
> Bron Gondwana <[e-mail]> wrote:
> >
> > This is not a problem that's unique to email.  There's nothing really
> > special about email here unless you make it special.  Sure there's a
> > bunch of indexed and optimised ways of viewing that data - sort by
> > trimmed subject, encodings, etc.  All of which could be expressed as
> > generic queries against the data model with a query optimiser on the far
> > end rather than needing a custom syntax for everything...
> 
> This sounds to me a bit more radical than I was expecting. In particular I
> thought you wanted to keep the data model so that existing servers could
> support the new protocol reasonably easily. Which implies that mailboxes
> remain separate silos rather than the store being a soup of messages
> GMail style.

Not really.  Existing servers would be a lot more efficient with a query
which limited to a single "folder", for sure - because they could optimise
it.  But it's no different than an SQL query across a partitioned table.
It means your in-memory-state needs to be big enough to accommodate all
the mailboxes that might be in the regular searches, of course.

But anyone accessing with an IMAP-model client would still access single
folders.  The only difference is that the model would accommodate
cross-folder requests as a first-order object, so you could sort them by
something other than "folder name first", which the existing cross-folder
solutions do.  If you're always sorting by folder first, you lose all the
benefits of having the server do it rather than the client synthesize the
results (the FastMail interface's cross-folder-search is a client
synthasize results thing - and it splits it up by folder... exactly
because the alternative means client-side sorting.  I wrote it many years
ago, and it does a "GUID" alternative which is "f${folderid}u${uid}" - kind
of ugly, and requires the "folder name to folderid" mapping in the database)

> > BEEP has also been mentioned.
> 
> I think BEEP is insane. Masses of complexity just to avoid using multiple
> concurrent TCP connections.

Yeah, I went and actually read the RFCs.  Inclined to agree.  It's
enterprisy in the extreme.

Now SCTP, that would be cool.  But support isn't there.

Bron.
-- 
  Bron Gondwana
  [e-mail]