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