Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP

[Bron Gondwana <[e-mail]>]

On Thu, Feb 16, 2012, at 08:10 PM, Adrien de Croy wrote:
> On 16/02/2012 7:56 p.m., Arnt Gulbrandsen wrote:
> > On 02/15/2012 11:25 PM, Dave Cridland wrote:
> >> This mailing list is "Discussion on drastically slimming-down IMAP", and
> >> you've listed the properties of ACAP, SIEVE, IMAP, CalDAV, CardDAV *and*
> >> Submission, and then thrown in a kitchen sink too.
> > As I see it, he's listed features which are in the Exchange protocol and
> > in the unnamed protocol spoken by gmail's javascript heap and its
> > mothership.
> >
> > That makes them worthy of discussion.
> >
> > I know IETF dogma is that protocols shouldn't overlap. But it's a weak
> > kind of dogma: IMAP overlaps with POP, POP overlaps with Submission,
> > various IMAP extensions with ACAP and what's that about IMSP? I could go on.
> 
> actually with a layered approach, this dogma could be maintained, as the 
> facilities would be able to be specified separately.
> 
> Would be interesting to see wire-line protocol on GMail - I bet they use 
> Json

Yes they do - with the "while(1);" hack at the top to stop it being scraped
by cross site tricks.  It's quite a clever workaround - any cross site request
that tries to embed the JSON URL just freezes - so the remote site can't
actually read the data.

We (mail.opera.com) also use JSON.  Ours is probably much less efficient over
the wire, because we chose readability over optimisation at this stage, so we
have named keys.  We will hopefully have two independent clients for it soon,
which will help us keep it stable.  I'm not sure that it's an ideal place to
start either though.  At least it was designed with a direct mapping to IMAP
in mind, so the data models are as similar as we could get (though we
"extended" IMAP to support the cross folder things we needed)

Bron.
-- 
  Bron Gondwana
  [e-mail]