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:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5