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

[Dave Cridland <[e-mail]>]

On Thu Feb 16 06:56:07 2012, 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'm mostly revelling in the irony.

> 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.

There's two huge problems with the approach.

Firstly, using a generic data model, or a generic protocol,  
automatically produces compromise. I've learnt to mistrust genericity  
in protocols - it all seems like such a lovely idea, and then  
everything turns into the bastard offspring of SQL. And the thing  
with SQL is that you can do useful things like indices and whotsits,  
which let you specialize the data store, but nobody ever gets that  
far. The only cases where this has worked is to partially specialize  
the datastore - LDAP/X.500 does this, as did ACAP - but only one of  
those has succeeded by any metric.

I'd note that, similarly, METADATA and ANNOTATE should have done  
well, if it weren't for the fact they expanded beyond a simple  
dumping ground for "everything else", and people tried to use them as  
the One True Datastore.

Secondly, the broader the scope, the bigger the task - I don't see  
any likelyhood of getting such a protocol sorted out before the end  
of the decade, or beyond. The phrase "boil the ocean" springs to  
mind. Remember, Exchange and the like are not successful because they  
do calendaring and mail, they're successful because they seamlessly  
blend calendaring and mail - the result is more than the sum of its  
parts, but making that blend will not be easy.

Aside from anything else - you want configuration storage services in  
$NEWPROTO? Well, I surely want these to have all the facilities that  
ACAP gives me. Calendaring? I'm sure that Cyrus will want it to have  
parity with, or exceed, CalDAV. Mail? There's any number of folk here  
who'll want their own special sauce in. And they'd be right, from  
their perspective, and the net result would be unimplementable.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade