Re: multipart, server-sent events, and

> Hmm, I wouldn't think so because that would be tunneling.

The difference between message separation with MIME multi-parts and HTTP 
messages is that multi-parts are separated by boundaries and HTTP messages 
are generally encapsulated by Content-Length (other ways too). The 
difference in efficiency is actually probably a wash. I just believe the 
semantics of HTTP messages are highly meaningful on the web. 
"multipart/message" is another another multipart format that indicates each 
part may have more headers than simply Content-Type (and transfer encoding), 
and therefore is more flexible than multipart/mixed, IMO...

> Anyhow, it
> doesn't really matter, as I wasn't necessarily trying to define
> something new.  I was - in a round about way - trying to ask whether
> it was worth living with the limitations of x-mixed-replace if there
> was only one implementation of it around.  If other browsers support
> it, then I'd guess it is worth it.  Alex says it almost works in
> Safari - presumbly via Webkit functionality - so that's a bunch of
> browsers there.

Even if it is based on a current implementation, the standard will be new, 
and it seems like we might as well as allow for other content types that are 
more reasonable than x-mixed-replace. It is not high-cost and it seems like 
good progress towards a more sane future.

>>  doing per-document connection accounting all the time would certainly 
>> not be
>>  opposed by us.
>
> I wonder if this is really necessary, since due to the same-domain
> constraint, publishers already have a large degree of control over how
> many connections their servers see since they're authoring the pages
> that create those connections.  I haven't given this as much thought
> as you guys though, so perhaps I'm missing something.

Publishers don't have control over how many tabs the user opens for the same 
site though. Four tabs to the same site means that the each tag/page may 
want it's own persistent connection to the server, but it is still one 
browser/agent.

>
>>  Another functionality that I believe would be extremely valuable to 
>> expose
>>  for XHR would be HTTP pipelining control. Most browsers do not provide 
>> HTTP
>>  pipelining because of compatibility concerns and performance 
>> implications of
>>  improperly order requests.
>
> I thought it was just that most proxies don't support it on the
> outbound connection.And I've never seen any ordering problems from
> the support, or lack thereof, of pipelining.

Yes, this is true. But browsers (at least firefox) do use heuristics to 
determine whether or not to pipeline requests (even when it is enabled). 
Admittedly, I don't what those heuristics are, but I presumed they were 
guesses about the extent of support. Also pipelining can possibly slow 
things down if a certain request takes a long time and it has requests 
stacked behind (that otherwise would have been diverted to another 
connection). All of these things web devs could have knowledge and control 
over though, and so opt-in pipelining could avoid these issues.

>
> FWIW, I suspect pipelining control could be targeted for XHR2.
>
> Would you be able to write this up as a concrete proposal for
> additions to one or both of the existing XHR spec or the (TBD) XHR2
> spec?

Yes. Are you referring specifically to pipelining, or other matters 
discussed? Either I will do that.
Thank you,
Kris

Received on Friday, 15 February 2008 22:45:02 UTC