Subject: [hybi] Shared long-polling idea

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 7 Jul 2009 20:42:57 -0500

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]

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 09 Jul 2009 17:16:32 +0300

Hi Martin,

the idea behind "a method for monitoring the state of multiple resources 
on the same server" is twofold
1) avoid to monopolise a connection for each resource, even considering 
the *two connection limit*
2) improve the usage of a connection, multiplexing traffic from 
different resources over it.

I am very happy you have write down this mail and started the discussion 
on how to solve the problem.

a first spontaneous comment:
in the current web application model there is not a need to discover in 
advance if a resource is a long-polling resource or not,
the client just declares to be ready to receive an asynchronous answer 
interrogating the resource using XmlHttpRequest method.
Then in theory, if a method for monitoring the state of multiple 
resource would be already available, the client could combine
the different XmlHttpRequest requests addressed to the same server and 
use this method directly.
So I don't see (but probably I am wrong) the need to clearly indicate 
that a resource is a long-polling resource.

about your proposal in general,
overloading/extending the GET method to monitor multiple resource has 
pro and cons that need to be evaluate carefully;
maybe it would be better using an extension method: what about MGET :-)

cheers
Sal

Thomson, Martin wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 9 Jul 2009 18:59:31 -0500

Thanks for the response Sal,

On rendezvous:
It's true that application knowledge can be used to determine whether a resource needs to be monitored, and I expect that most applications will need this information.

However, if this information is constrained to the application layer, a shared HTTP layer cannot use that information.  By making the information available at the HTTP layer, an HTTP implementation can assist.

Say that I have two tabs open to the same site.  Each uses long-polling to monitor the state of a resource.  If the common HTTP layer is unaware of this - it is forced to use a heuristic to just determine that long-polling is being used.  Even then, there is no way to tell that the server supports combination.  By making it obvious that the resource is "special", and by indicating support for combining, the HTTP layer can act.

We have to assume that the application layer entities cannot (or wont) do this for a number of reasons:
 - they might not have knowledge of the other's existence
 - they have no incentive to optimise in this fashion (i.e. effort with no tangible reward)
 - mostly, they just don't have the ability to do anything about it

Both the server and common HTTP part of the client have the ability to do something and plenty of incentive to do so.  By making the agreement at the HTTP layer, they are able to collude without permission (or assistance) from the application layer.

On GET/MGET: the advantage of just using GET is that I can use an unaware intermediary (cache/proxy) and it works.  That's a hard goal to meet with a new method.

It's also consistent with the idea of increasing the scope of content-negotiation.

--Martin

> -----Original Message-----
> From: Salvatore Loreto [mailto:[email-masked]]
> Sent: Friday, 10 July 2009 12:17 AM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [hybi] Shared long-polling idea
> 
> Hi Martin,
> 
> > 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 :)
> >
> >
> > 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.
> >
> > 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.)
> >
> >
> > 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
> >
> > 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

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 13 Jul 2009 17:08:37 +0300

Hi Martin,

I have been thinking for a couple of days on this,
and I have to say that you are right that making the information (that a 
resource needs to be monitored) at HTTP layer can help in several scenarios.

actually I think that the usage of Link: header [1] can help in both
- provide a sign that a resource needs to be monitored (e.g. returning a 
link relation containing an URI with a relation type of "monitor")
- provide a way to group multiple resource on the same server (e.g. 
returning for all the resource that can be grouped the same link 
relation containing an URI with a relation of type "group-monitor")
  (reusing the idea described in draft-roach-sip-http-subscribe-02 ).

about the idea of increasing the scope of content-negotiation I haven't 
had the time to think more on it, but it seems an interesting idea!

I agree on the fact that a new method is an hard goal, and that re-using 
GET would be much better and easy.

/Sal

[1] 
http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-06.txt

Thomson, Martin wrote:
>>> (This is a generalization of the single browser operating multiple
>>>       
>> tabs scenario, if you like.)
>>     
>>> Say that resource B has information available first.  The response
>>>       
>> is:
>>     
>>>   HTTP/1.1 200 OK
>>> ---------------------------------------------------------------------
>>>       
>> ---------------------------
>>     
>>> ---------------------------------------------------------------------
>>>       
>> ---------------------------
>>     
>>> [mf2]

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Jul 2009 12:19:46 +1000

I'm very much in agreement that explicitly giving each thing to be  
monitored a separate URI is a good thing to do, because it sympathises  
with the current Web. Long-polling for something is just one way to  
get its state; you might also learn about it by GETting it, or seeing  
it in an Atom feed, etc.

In designing a mechanism to monitor multiple URLs, I think one  
critical question is where the state of the URLs to be monitored lives.

The approach that Martin outlines puts the state in the request; i.e.,  
every time you poll, you describe the resources to be monitored. This  
uses content negotiation, which has its own challenges; e.g., it  
doesn't interoperate well with many cache implementations, and it  
doesn't scale when what's being negotiated is complex.

Another approach would be to have the server keep this state. E.g., a  
client that wishes to monitor would POST or PUT a resource onto the  
server describing what URLs are to be monitored, and then long poll  
that resource.

The disadvantage here is that the server needs to keep some state, but  
it isn't necessarily client-specific state; if specified well,  
multiple clients could share state, and the server could decide to  
optimise (e.g., directing the client to a channel that's a superset of  
the resources that they ask for, trading off those extra events for  
reduced server-side state, and more potential for caching and  
multiplexing by intermediaries).

Having a response link to a URL that can be used to monitor it is also  
interesting, and may be complimentary to this.

Cheers,

On 14/07/2009, at 12:08 AM, Salvatore Loreto wrote:

> and I have to say that you are right that making the information  
> (that a resource needs to be monitored) at HTTP layer can help in  
> several scenarios.
>
> - provide a sign that a resource needs to be monitored (e.g.  
> returning a link relation containing an URI with a relation type of  
> "monitor")
> about the idea of increasing the scope of content-negotiation I  
> haven't had the time to think more on it, but it seems an  
> interesting idea!
>
> I agree on the fact that a new method is an hard goal, and that re- 
> using GET would be much better and easy.
>
> /Sal
>
> [1] http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-06.txt
>
>
>
>
> Thomson, Martin wrote:
>> It's true that application knowledge can be used to determine  
>> whether a resource needs to be monitored, and I expect that most  
>> applications will need this information.
>>
>> However, if this information is constrained to the application  
>> layer, a shared HTTP layer cannot use that information.  By making  
>> the information available at the HTTP layer, an HTTP implementation  
>> can assist.
>>
>> Say that I have two tabs open to the same site.  Each uses long- 
>> polling to monitor the state of a resource.  If the common HTTP  
>> layer is unaware of this - it is forced to use a heuristic to just  
>> determine that long-polling is being used.  Even then, there is no  
>> way to tell that the server supports combination.  By making it  
>> obvious that the resource is "special", and by indicating support  
>> for combining, the HTTP layer can act.
>> Both the server and common HTTP part of the client have the ability  
>> to do something and plenty of incentive to do so.  By making the  
>> agreement at the HTTP layer, they are able to collude without  
>> permission (or assistance) from the application layer.
>>
>> On GET/MGET: the advantage of just using GET is that I can use an  
>> unaware intermediary (cache/proxy) and it works.  That's a hard  
>> goal to meet with a new method.
>>

--
Mark Nottingham     http://www.mnot.net/

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 16 Jul 2009 22:57:59 -0500

Hi Mark,

I'd like to explore your suggestion of using server state a little more, because I think that there is something missing.

What you propose would work well enough, but can it work without application layer assistance?  Presumably, you require that a server is aware of all resources that might be long-polled.

In response to your critique, I understand that what I proposed is absolutely un-cacheable and why caches (and proxies) would be unable to assist.  As I understand, the client would have to put a Cache-Control header in the request for the benefit of the proxy/cache only.

To some extent, this problem can only be rectified by deciding on a solution, then awaiting implementation updates.  In the meantime, provide a means to fool un-updated code such that it degrades, but doesn't degrade to the point that it prevents the request from succeeding.

For instance, a long-polling client might be able to do something like:

  Cache-Control: no-cache, long-poll=share

This could mean that the cache must not supply data from cache.  The 'long-poll' tag means that long-poll-aware caches can consolidate requests from multiple clients and make a single request.  Caches without this awareness continue to do the end-to-end reload.

Cheers,
--Martin

p.s. Some day, I'd like it if someone explains to me why a cache can't just use Content-Location.  That is, why it's necessary for HTTP to prohibit caches from caching a resource when the location of that resource is indicated by a Content-Location header rather than the request URI?

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mark Nottingham
> Sent: Friday, 17 July 2009 12:20 PM
> To: Salvatore Loreto
> Cc: [email-masked]; Thomson, Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 16 Jul 2009 23:04:14 -0500

My apologies, I got caught up looking at solutions to problems, then forgot to finish my other train of thought.

Assume that the server knows of the long-polling resources in a logical set: /lp/1, /lp/2, and /lp/3.  I assume that you're suggesting that it redirects requests to each of these to a single resource /lpc.  I presume that a client will go to this location and poll there.  

One client goes to /lp/1, is redirected to /lpc.  But the first update changes /lp/3, what then?  Presumably, the response contains Content-Location: /lp/3, but how is the client to know that this is not the information it was looking for without application layer knowledge?

--Martin

> Thomson, Martin
> Sent: Friday, 17 July 2009 1:58 PM
> To: Mark Nottingham; Salvatore Loreto
> Cc: [email-masked]
> I'd like to explore your suggestion of using server state a little
> more, because I think that there is something missing.
> 
> What you propose would work well enough, but can it work without
> application layer assistance?  Presumably, you require that a server is
> aware of all resources that might be long-polled.
> 
> In response to your critique, I understand that what I proposed is
> absolutely un-cacheable and why caches (and proxies) would be unable to
> assist.  As I understand, the client would have to put a Cache-Control
> header in the request for the benefit of the proxy/cache only.
> 
> To some extent, this problem can only be rectified by deciding on a
> solution, then awaiting implementation updates.  In the meantime,
> provide a means to fool un-updated code such that it degrades, but
> doesn't degrade to the point that it prevents the request from
> succeeding.
> 
> This could mean that the cache must not supply data from cache.  The
> 'long-poll' tag means that long-poll-aware caches can consolidate
> requests from multiple clients and make a single request.  Caches
> without this awareness continue to do the end-to-end reload.
> 
> Cheers,
> --Martin
> 
> p.s. Some day, I'd like it if someone explains to me why a cache can't
> just use Content-Location.  That is, why it's necessary for HTTP to
> prohibit caches from caching a resource when the location of that
> resource is indicated by a Content-Location header rather than the
> request URI?
> 
> 
> > >>> the different XmlHttpRequest requests addressed to the same
> server
> > >>> and
> > >>> applications indicate a need for long-polling.  Without going
> into
> > >>> too
> > >>> behaviour are likely to demand one.  Therefore, it's probably
> best
> > >>> to
> > >>>> ----------------------------------------------------------------
> --
> > ---
> > >>>>
> > >>>> ----------------------------------------------------------------
> --
> > ---
> > >>>>
> > >> ------------------------------------------------------------------
> --
> > ----------------------------
> > >> ------------------------------------------------------------------
> --
> > ----------------------------
> > >> [mf2]
> > >>
> > >

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Jul 2009 15:05:01 +1000

On 17/07/2009, at 1:57 PM, Thomson, Martin wrote:

> application layer assistance?  Presumably, you require that a server  
> is aware of all resources that might be long-polled.

It depends on what you mean by "application-layer assistance."

> absolutely un-cacheable and why caches (and proxies) would be unable  
> to assist.  As I understand, the client would have to put a Cache- 
> Control header in the request for the benefit of the proxy/cache only.
>

That would be one way to do it, yes.

>
> Cheers,
> --Martin
>
> p.s. Some day, I'd like it if someone explains to me why a cache  
> can't just use Content-Location.  That is, why it's necessary for  
> HTTP to prohibit caches from caching a resource when the location of  
> that resource is indicated by a Content-Location header rather than  
> the request URI?

That's still to be discussed in HTTPbis...

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Jul 2009 15:14:19 +1000

I'm saying that one possible pattern would be:

 > POST /some/uri/for/minting/polling/resources HTTP/1.1
 > Host: example.com
 > Content-Type: application/list-of-interesting-uris
 > Content-Length: ...
 >
 > /lp/1
 > /lp/2
 > /lp/3

< HTTP/1.1 201 Created
< Content-Type: text/plain
< Content-Length: ...
< Location: /poll/resources/1
<
< Look over there to find out what about these resources.

 > GET /poll/resources/1 HTTP/1.1
 > Host: example.com
 > Connection: I-wanna-long-poll

[ time passes ]

< HTTP/1.1 307 Temporary Redirect
< Location: /lp/1
< Content-Location: /lp/1
< Content-Type: application/foo
<
< application stuff here.

and so on. A 307 is just one possibility here; the important part is  
crisping up what the semantics of the polling resource are. It could  
also be an Atom feed of the recent events in the feed, etc.

My point is that there are lots of ways to do this that are compatible  
with the Web, but using conneg for it doesn't seem like one of them.  
While it's technically possible to abuse conneg into what you want to  
do, it's also technically possible to serve and entire Web site  
through one URI using connect. Doesn't mean it should be done.

Cheers,

On 17/07/2009, at 2:04 PM, Thomson, Martin wrote:

> My apologies, I got caught up looking at solutions to problems, then  
> forgot to finish my other train of thought.
>
> Assume that the server knows of the long-polling resources in a  
> logical set: /lp/1, /lp/2, and /lp/3.  I assume that you're  
> suggesting that it redirects requests to each of these to a single  
> resource /lpc.  I presume that a client will go to this location and  
> poll there.
>
> One client goes to /lp/1, is redirected to /lpc.  But the first  
> update changes /lp/3, what then?  Presumably, the response contains  
> Content-Location: /lp/3, but how is the client to know that this is  
> not the information it was looking for without application layer  
> knowledge?
>
> --Martin
>
>> can't

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 17 Jul 2009 00:31:43 -0500

That's workable, certainly.  I didn't want to imply that one way was better than t'other, I just wanted to be clear on the characteristics.

It's not insurmountable, but the point that I was making was that in order to do this, or anything like it, this can't be unilaterally applied by an HTTP layer operating in ignorance of the application.

For this to work, the HTTP layer needs to be aware that these three resources can be consolidated thus.  That requires knowledge from some other layer.  Or, something needs to be put on the HTTP layer.  Otherwise, as I said, the application layer needs to get involved, recognise three long-poll resources and tie them together.

I have no opinion on whether conneg is abuse or not.  If it doesn't play well with intermediaries, then it's unsuitable and I'll happily label it abuse.  Currently, I'd expect that intermediaries rarely make a positive contribution when long-polling is involved; so whatever we do, this situation can only improve.

I consider it unlikely that this improvement is possible with existing intermediaries - after all, the intent of this sort of long-poll is to say: "don't tell me what the resource is now, tell me what it becomes when it changes".  Existing caches can't do anything about that; they could, if they could be made aware of the nature of the transaction.

--Martin

> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Friday, 17 July 2009 3:14 PM
> To: Thomson, Martin
> Cc: Salvatore Loreto; [email-masked]
> >>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of
> >>> Mark Nottingham
> >>>> [1] http://www.ietf.org/internet-drafts/draft-nottingham-http-
> link-
> >>> header-06.txt
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Thomson, Martin wrote:
...

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Jul 2009 14:08:44 +1000

On 17/07/2009, at 3:31 PM, Thomson, Martin wrote:

> That's workable, certainly.  I didn't want to imply that one way was  
> better than t'other, I just wanted to be clear on the characteristics.
>
> It's not insurmountable, but the point that I was making was that in  
> order to do this, or anything like it, this can't be unilaterally  
> applied by an HTTP layer operating in ignorance of the application.

Completely, I think we're in agreement here. HTTP *is* an application- 
layer protocol, and therefore does need some knowledge of it.

The interesting part is surfacing those application semantics in a way  
that a generic intermediary can do something with them. As you point  
out, that's probably not going to be an intermediary that exists  
today...

Cheers,

> For this to work, the HTTP layer needs to be aware that these three  
> resources can be consolidated thus.  That requires knowledge from  
> some other layer.  Or, something needs to be put on the HTTP layer.   
> Otherwise, as I said, the application layer needs to get involved,  
> recognise three long-poll resources and tie them together.
>
> I have no opinion on whether conneg is abuse or not.  If it doesn't  
> play well with intermediaries, then it's unsuitable and I'll happily  
> label it abuse.  Currently, I'd expect that intermediaries rarely  
> make a positive contribution when long-polling is involved; so  
> whatever we do, this situation can only improve.
>
> I consider it unlikely that this improvement is possible with  
> existing intermediaries - after all, the intent of this sort of long- 
> poll is to say: "don't tell me what the resource is now, tell me  
> what it becomes when it changes".  Existing caches can't do anything  
> about that; they could, if they could be made aware of the nature of  
> the transaction.
>
> --Martin
>
>>>> Behalf Of
>>>>> optimise (e.g., directing the client to a channel that's a  
>>>>> superset
>>>> of
>>>>>>> - they have no incentive to optimise in this fashion (i.e.  
>>>>>>> effort
>>>>>>> with no tangible reward)