On Sat, 13 Aug 2005, Benjamin Carlyle wrote:
I've done a small write-up of my current thinking at http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/2005/08/07#internetSubscription I think it's clear that even my updated model is flawed. Trying to hold off waiting for a change before sending a response is bound to cause major disruption to (unaware) proxy connection handling. It seems that the HTTP protocol can't be extended safely (ie in a way that doesn't harm older proxies) to support a subscription protocol of the ilk I've been considering.
Maybe, maybe not. Depends on what requirements can be put on the server side.
To send a multiple-subscription you need something outside the TCP/IP connection tying the subscriptions together. Any unique identifier known to both client and server is good for this.
The same applies for long-running subscriptions, allowing the client subscription channel to be reestablished at any time.
You are correct in that HTTP is not designed for this. HTTP is designed for simple client initiated transfers of relatively small objects (kbyte range). Trying to impose server side initiated transfers on HTTP is not an easy task as it is orthogonal to how the protocol works. For this to at all work you need to have the client poll for chages.
And to work via HTTP proxies the protocol must be designed in such manner that it does not rely on individual TCP/IP connections (only HTTP messages) and accepts reordering of pipelined requests.
The distribution mechanism in HTTP caching is based on two (often false, but more often not) assumptions:
* For important data it is known when the next change will occur, allowing proper Expires or Max-age information to be returned indicating how long this data is valid for this kind of request.
* For other data (or where the published does not care or know about freshness) the more recently the data was changed the more likely it is to change soon.
and from this caches (client and proxy based) deduces when it is best to check with the server if the content has chaned, and only if the end-user-agent is actively asking for the data at the time.
HTTP is strongly designed around a server->client concept, but also accepts client initiated transfers in the other direction (but not cached by any means).
Regards Henrik
