multipart, server-sent events, and

Howdy all:

So after some brief discussions with Anne and Hixie, I want to start a  
discussion about some of the open issues I see not being addressed  
regarding server-sent data. This was agreed as the correct forum for  
the discussion. I see several major issues that need resolution:

	* what will become the (defacto) standard for multiple events over a  
single connection?
	* what will be done to prevent the current 2-connection limit from  
locking browsers?

First, as background, there are at least 2 partially-implemented  
solutions available in browsers today. Opera has included an  
implementation of the WHATWG's sever-sent events, which rely on a  
simple wire format. The other native option for receiving multiple  
messages without closing/re-opening a connection is the multipart/x- 
mixed-replace system (currently implemented in a semi-workable fashion  
by Mozilla).

Given that WHAT-WG seems to be leaning away from server-sent events,  
and noting that neither approach solve the 2-connection limit problem,  
I'd like to propose the following for consideration:

	* that multipart/x-mixed-replace for textual content over XHR be  
fully specified by this working group
	* that a new XHR readyState be defined for "message end" as distinct  
from HTTP connection close or that some other property or event be  
made available to test for overall connection state
	* that a new settable property be added to XHR objects which controls  
how the HTTP connection created by the object is accounted for against  
the HTTP 1.1 specified 2-connection limit.

Today, if multiple tabs open Comet connections to the same originating  
server, no document in the browser may request any resources from that  
server, effectively "locking" the domain from further use until one of  
the Comet connections is closed. Instead of a blanket "bump" to the  
connection limit (which has un-desireable consequences for existing  
servers), it may be preferable for servers to be able to provide a  
header which effectively discounts the connection or a client-side  
toggle which allocates the connection against a different, per- 
document limit of connections (up to some high global maximum).

Thoughts?

--
Alex Russell
alex@sitepen.com     A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
alex@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723