W3C TAG

Lucas Gonze lucas@gonze.com
Sat, 22 Dec 2001 14:06:02 -0500


SUBSCRIBE is an elegant idea, Mssr. FoRK.  It's a notification of a state
change, e.g. of a POST having been performed, and because it's about state it
fits into a RESTy model for understanding the web.  (somehow or other, anyway,
given that the Roy model isn't canon and isn't even very generalized beyond
hypertext).

It's a big can of worms to open.  On a practical level you either need an
ongoing backstream on the SUBSCRIBE or you need a callback URL.  If there's a
callback URL then there's a web server on the client.

I wonder if there's a way to model SUBSCRIBE as a combination of existing
methods?

> > No ability for clients to receive file update events asynchronously.
> >
> > EG:
> > Clients A and B are both using file F.  Client A modifies the file.
> Client B
> > doesn't receive the update until it explicitly asks the server for it.
> How about we introduce an HTTP SUBSCRIBE method? Like a GET on future state
> changes.
> Echoes any incoming requests (whatever client A does is echoed to Client B -
> but it probably would be more useful if the intermediary sent a simplified
> message, otherwise everybody has to be a dav server)