[hybi] Intermediaries

[Kris Zyp <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
It has been mentioned before that we would ideally like the
bidirectional web protocol to be comprehensible at some level by
intermediaries. While I know it is not possible to envision every way
that an intermediary might be used, I think it is worth considered
possible benefits that can be derived from intermediaries and how to
facilitate that. Some of the main benefits that intermediaries can
provide is in scalability, multiple intermediaries can handle
requests, diverting the load from the final server. Providing faster
response times for users in various locations with local edge-placed
servers is also an important benefit of intermediaries. The designers
of HTTP understood this, and I think we would do well uphold a design
that can scale well across across multiple machines and locations.

I would suggest two possible ideas within the bidirectional web
protocol that could help facilitate efficient use of intermediaries:

* Subscription mechanisms defined in the protocol - The client/server
reverse of proxied caching is essentially multicasting. If an
intermediary can understand the protocol for how subscriptions are
made (by client request, generally), and they can understand which
messages should be delivered to different subscribers, then they can
effectively act as a multicaster of server originated messages to
clients. A proxy can receive handle multiple clients subscribing to
the same topic, create a single subscription to the central server,
and then when messages are received from the server for the given
topic, they can disseminate the topic to all the subscribed clients.
The central server only needs to be concerned with the single client
(the proxy server), and the work is offloaded.

* HTTP cache updating - I think there is an opportunity for the
bidirectional web protocol to more than merely coexist with HTTP, but
it could also complement it, if it could participate in the caching
infrastructure of HTTP. If a class of messages sent from a server
could signal that a resource was create, updated, or deleted, and
include an updated representation of that resource, the location and
appropriate metadata (media type and any other meta data that the
cache must "Vary" on) the message could be used to update HTTP caches
with the latest version for the given resource representation.

A very common use case for server originated messaging is to notify
clients of changes to server-side resources. If such messages were
defined by the bidirectional protocol, there would standard mechanism
for notifying clients in a way that intermediaries could benefit from.
This would also allow HTTP proxies to be more effective; cached
entities could be kept in caches for much longer periods of time
(indefinitely) if a proxy was maintaining a subscription such that it
would be notified if the resource ever changed.

It would be possible for users to each create their own custom
definition of resource update notification, but if it was not
standardized such that intermediaries would understand, the only way
for clients to cause the intermediaries to be updated would be to
reissue a GET request for the resource, which would result in
server-to-client, client-to-server, and server-to-client trips, rather
than a single server-to-client trip. I don't think tripling the
latency overhead is really practical for most users that are needing
bidirectional communication, which should seems unfortunate, as I
believe notification of server side resource updates is one of the
most common usages of bidirectional communication (even if it is not
always stated in RESTful terms).

- --
Kris Zyp
SitePen
[phone]
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkqEgZsACgkQ9VpNnHc4zAwRTACcDJjq3Blek1UhyVbIEppe38FV
qNIAn1ollcKnsHL4NaQvNUoPme5x6POi
=BmkV
-----END PGP SIGNATURE-----