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

[Bron Gondwana <[e-mail]>]

On Mon, Feb 13, 2012 at 10:20:45AM -0500, Cyrus Daboo wrote:
> I disagree because what I envisage for the generic notification
> service is an OS-level api (supplied by OS or 3rd party libraries)
> that implement the "internet push service protocol". What that means
> is that client developers only have to implement a simple api to get
> push notifications. What is more anyone implementing more than one
> protocol in their client (e.g. IMAP, CalDAV and CardDAV) would only
> have to implement that once, albeit with some minor differences in
> regard to how to get protocol specific pieces for registering for
> notifications.

That's my vision too.  Ideally not pushing a full data feed, but
just a "ping, there's new stuff for you".  Otherwise you wind up
embedding every other protocol inside this protocol, which is
too meta, even for me.

> 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. But, IMHO, you
> are really going to have to up-sell IMAP5 to get buy-in from the
> major email providers. Now that does not mean it is not worth doing,
> but it does mean having to do more than just fixing perceived or
> real deficiencies.

Absolutely agree.  We need a hook to make it worthwhile, and I
think submission and reliable push notifications are the hook.

I've updated my RFC list from a simple text file which generates
the list.  Makes it easier to add new items :)  Of course it means
I miss any changes that anyone else makes to the wiki now - so I'll
have to write a reverse parser too so I can see a diff first.

The tricky bit is that the providers for whom it's going to be the
most work are the ones who aren't already doing the LEMONADE profile,
since that requires the sort of datastructures that would support
the things I want to do with re-syncable state.

Bron.