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

[Bron Gondwana <[e-mail]>]

On Mon, Feb 13, 2012 at 07:00:48PM +0000, Alexey Melnikov wrote:
> On 13/02/2012 16:23, Bron Gondwana wrote:
> >On Mon, Feb 13, 2012 at 10:20:45AM -0500, Cyrus Daboo wrote:
>  [...]
> >>Your point about actually getting this done is valid. But
> >>realistically, do you really think IMAP5 is going to deploy
> >>overnight? Frankly, anyone who has a reasonably solid IMAP4
> >>implementation today is going to question the need to work on
> >>something new, particularly if that something new brings nothing to
> >>the table (and simply fixing interop problems will probably not be
> >>seen as something "new"). If you can actually show that IMAP5 adds
> >>significant value by doing things like helping centralize push
> >>notifications, simplifying submission etc, then maybe, just maybe,
> >>those existing implementors might actually consider throwing out
> >>their current investment in IMAP4 for the new thing.
> I agree. But I think another important point is that Bron not
> suggesting to throw away everything and start from scratch. Maybe it
> is just me, but I am hoping that if this effort takes off, then lots
> of capabilities/commands of IMAP4+extensions will be preserved as
> is, so that upgrading an existing IMAP4 implementation would be
> relatively easy.

Absolutely preserved in semantics if not in syntax.  The semantics
are pretty good, mostly - and the ones that I don't like are mostly
the "magic" bits.

Being able to plug this in as another access method to an already
existing IMAP store is a very important property - at most it
would require a little extra indexing if you want to be efficient.

Even more ideally, you could implement a connector either way at
a loss of efficiency - an (at least basic) IMAP connector in front
of this protocol, or a proxy for this protocol (caching quite a lot
more information probably - particularly if the backend didn't have
a concept of MODSEQ) in front of an existing IMAP store.

Bron.