Subject: [hybi] Intermediaries

From: Kris Zyp <[email-masked]>
Date: Thu, 13 Aug 2009 15:11:55 -0600

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
(503) 806-1841
http://sitepen.com

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 17 Aug 2009 14:46:12 +1000

Kris,

+1 on supporting intermediaries.

I think it is important to at least allow intermediaries to cleanly
close connections without routine loss of messages and retry+idempotency
complications.

Multiplexing support is also key if intermediaries are going to
be capable of doing much intelligent stuff.

More in-line....

Kris Zyp wrote:
> * Subscription mechanisms defined in the protocol

I can't believe that I'm about to type this.... because I
really like subscription mechanisms....   With cometd/bayeux,
I think one of the biggest sources of confusion has been that
subscription is built into the protocol, so that while non-subscription
delivery is supported, people just don't get it and those that
don't want subscription are very anti the bayeux protocol.

So I would say approach subscription with caution... and
potentially specify it as a layer on top of the base protocol.

As you say, multicast is a big win for the subscription model
( as used Oort Cometd cloud).

> * HTTP cache updating 

Neat idea.   I also think that the bidirectional protocol
should be able to carry regular HTTP request/responses as
well.    It would be strange if you had a fully capable
bidirectional connection, but had to crack open another
TCP/IP connection just to get favicon.ico

You could almost consider that caching mechanism an
extension of the subscription mechanism.  If you
subscribed to favicon.ico you would be sent that
resource again whenever it updated.

cheers