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