- From: Cyrus Daboo <cyrus@daboo.name>
- Date: Tue, 15 Apr 2014 10:06:05 -0400
- To: Peter Saint-Andre <stpeter@stpeter.im>, Ken Murchison <murch@andrew.cmu.edu>, WebDAV <w3c-dist-auth@w3.org>
Hi Peter, --On April 9, 2014 at 10:57:31 AM -0700 Peter Saint-Andre <stpeter@stpeter.im> wrote: > Well, I mention this Internet-Draft mostly to show that people have been > thinking about this problem for at least 10 years. You could use XMPP for > such notifications, although it might depend on what kinds of endpoints > you're trying to support (e.g., do they or can they do XMPP). Other > options are technologies like pubsubhubbub. There are also lots of > proprietary technologies for such notifications, although of course we > don't want anything proprietary. However IMHO long polling is not the > best approach these days - we wrote RFC 6202 mostly to say that long > polling is a bad idea and that it's better to use WebSockets instead (RFC > 6455). But WebSockets only gives you "TCP for the Web" and you'd need to > define some kind of application over WebSocket in order to get anything > done (examples are SIP over WebSocket, XMPP over WebSocket, etc.). So the big issue here of course is that nothing has happend to standardize a general solution to push, so we do have proprietary solutions. There are really two parts to what we would like to do here: 1) Recognizing that multiple proprietary solutions exist today, clients currently have to "probe" a server (or use hard-coded defaults based on hostnames) to determine which one is actually supported. What would be better is if there was a standard way for servers to advertise support for any type of push protocol. That could simply be specific DAV header items, or a WebDAV property that enumerates what is supported (be it proprietary or any new standard approach). 2) Some client folks have expressed interest in having a base "minimum to implement" standard push protocol that would suffice for at least desktop-based clients (recognizing that the mobile environment is a lot trickier to deal with - though of course no less important these days). The initial thought we had was to go the route of IMAP's IDLE command - i.e., make use of the existing protocol to provide an in-band solution. Long-polling with the WebDAV sync REPORT would seem like the best fit for that approach - but operational concerns with that obviously come into play. Now, if the time is ripe for the IETF to tackle the push problem in a more generic way, then lets do that - but I'm not optimistic given the past history and the current diversity of proprietary solutions. -- Cyrus Daboo
Received on Tuesday, 15 April 2014 14:07:54 UTC