-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This message from the [email protected] list might be of interest here, especially with regard to the "Shared BOSH" proposal:
http://xmpp.org/extensions/inbox/shared-bosh.html /psa - -------- Original Message -------- Subject: [hybi] Shared long-polling idea Date: Tue, 7 Jul 2009 20:42:57 -0500 From: Thomson, Martin <[email protected]> To: <[email protected]> Reading over the long-polling draft (draft-loreto-http-bidirectional) and its list of goals, I'd like to share some thoughts on one of these points. Namely, "A method for monitoring the state of multiple resources". (This is probably something I should put in a draft, but I'll start with an email. That way I haven't invested too much effort if this turns out to be incompatible with what others are thinking :) Requirement: Common or shared HTTP layer It's common for there to be multiple application contexts in a single device or application. Each application context independently maintains state. These application contexts might share a common HTTP and network layer. The common layer manages TCP connections and might also provide a cache. (This is a generalization of the single browser operating multiple tabs scenario, if you like.) If each application context happens to be interacting with resources on the same server, it makes sense for the network layer to coordinate activities. Coordination at this layer means that resources can be cached and network resources can be shared. Users get improved responsiveness; networks get less traffic and less congestion. For the standard "pull" pattern employed for HTTP, this works admirably, but change to long-polling and sharing becomes complicated. Let's see what can be done to accomplish a degree of sharing, and explore the limitations. Say that the application contexts interact with resource A (http://example.com/a) or resource B (http://example.com/b). Both applications indicate a need for long-polling. Without going into too much detail, let's assume that the target of the long poll is a special purpose server, and the target URI identifies the application context. Resource A indicates (http://lp.example.com/ctxt/a) and resource B indicates (http://lp.example.com/ctxt/b). Without any support for sharing in the protocol, long-polling to these resources requires a connection for each. A long-poll to a single resource monopolises a connection for the duration. No sharing at all. (It's no surprise then that BOSH and Bayeux both provide multiplexing capabilities. It's just a shame that HTTP isn't able to help - all this is done by introducing an intermediate layer.) Long-Poll Sharing To enable sharing at this layer, the common network layer would need to be able to make a single request on the one connection. But how is this to be achieved? Such a request would have to indicate that it is intended for either of the two URI. On first impressions, that seems contrary to the way that HTTP operates. That is, until you think about what content-negotiation really is: identifying a set of resources and picking the one that is most appropriate. It's just that content-negotiation is currently limited to content type, language, encoding and those sorts of things. As a strawman, let me suppose that a new HTTP header is minted for this purpose: Accept-Resource. This header includes a list of URIs, indicating the set of resources that could be provided. Thus, this one request indicates a willingness on the part of the client to receive one of a set of resources and the server provides the most appropriate in the response. "Most appropriate" in this context probably means whichever of the two applications has information (or a request) for the client first. The response then contains a Content-Location header (or maybe Location?) that indicates which of the resources was provided. For now, let's just assume that this is one of the URIs from the Accept-Resource set, so that the common layer can correctly identify which application context to provide the information to. (This probably needs more thorough consideration.) Request-URI, Accept-Resource Interaction This request is, in effect, a request for one of a set of multiple resources. Thus, the request URI is but one of the set of possible options. Of course, intermediaries that are unaware of this new behaviour are likely to demand one. Therefore, it's probably best to select one from the set of resources and put that URI on the request line. The remainder go in the Accept-Resource header. Thus we have: GET /ctxt/a HTTP/1.1 Host: lp.example.com Accept-Resource: /ctxt/b Say that resource B has information available first. The response is: HTTP/1.1 200 OK Content-Location: /ctxt/b ... Rendezvous Logic The problem with this approach is that there is a need to clearly indicate that a resource is a long-polling resource. Only with this knowledge, can a client act to combine separate requests. It's one thing to place this knowledge at the layers above HTTP, but for a shared HTTP layer to provide any value, that information needs to be available at that layer as well. This ties in with the "Improved rendezvous logic" item. The simplest method that I can think of is to allow clients to spawn multiple connections initially, but provide some indication in the first response that indicates the resource is special. No existing pieces seem like a good fit; maybe a new header is needed. I have an idea on this front that might just work for my ends. I'll follow up with that and see if it works for anyone else. - --Martin - ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. - ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ hybi mailing list [email protected] https://www.ietf.org/mailman/listinfo/hybi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpT/v0ACgkQNL8k5A2w/vxVZACfUapJsdUw8pLWcwXIeFShRP68 JUgAniyzgqxZCm9ZB7GHo+VMFiVOnCm8 =VCym -----END PGP SIGNATURE-----
