You need to
before you can comment on or make changes to this bug.
Add support for multipart/x-mixed-replace to XMLHttpRequest as was done in Firefox. Please use same method calls so API is compatible between WebKit, Safari & FireFox.
Please note that support for multipart/x-mixed-replace is not even considered for inclusion in future versions of XMLHttpRequest spec yet, as seen in the current draft of the spec, <http://www.w3.org/TR/XMLHttpRequest/#notcovered>. We may want to discuss its possible standardization first.
HTML5 seems to have <event-source> for server push.
(In reply to comment #2)
> HTML5 seems to have <event-source> for server push.
<event-source> seems nice at first glance, but it will have a number of problems and is re-inventing the wheel (poorly).
The data format for sending events is too simplistic. It won't support binary data well. This will force the use of encoding schemes like base64 for pushing binary data. Base64 encoding of binary data is inefficient because it increases the data size by 1/3. Imagine increasing your bandwidth usage by 1/3 across thousands of users - not a good thing.
Encoding scheme's also require more CPU and nearly twice the memory on both the client and server. One in-memory copy of the encoded data and one in-memory copy of the decoded data while the encoding/decoding is taking place. Why use twice the memory on both the client and server and waste CPU to do encoding/decoding? This severely reduces the scalability of an application. Base64 is just an example, any encoding scheme will have similar problems.
This wouldn't be necessary with multipart/x-mixed-replace because it is based on MIME and handles binary data well without encoding. Additionally multipart/x-mixed-replace supports a unique content-type and other headers for each content chunk. This isn't currently available with <event-source>.
People expect to use XmlHttpRequest for interacting with the server. This is an evolutionary step for XmlHttpRequest. It could honestly be considered a bug that XmlHttpRequest doesn't support multipart/x-mixed-replace because that is a valid content type that has existed for some time.
As more "desktop" applications move to the web I expect features like the ones provided by Google Gears and Adobe Air (formerly Apollo) to migrate into web browsers. This would cause a problem with <event-source> because when multiple "threads" are supported by a browser the UI thread would still be involved in handling server events. With XmlHttpRequest, server interaction could be moved into the background and only when the UI is updated will the UI thread need to be involved.
(In reply to comment #1)
> Please note that support for multipart/x-mixed-replace is not even considered
> for inclusion in future versions of XMLHttpRequest spec yet, as seen in the
> current draft of the spec, <http://www.w3.org/TR/XMLHttpRequest/#notcovered>.
> We may want to discuss its possible standardization first.
Standardization happens via 2 routes. Route 1, everyone gets in a room and creates a spec with little or no real world experience. These specs sound great on paper, but usually have a great deal of problems when people try to implement them.
Route 2, someone comes up with an innovative idea and everyone says "Wow, that's cool". They then copy that idea as closely as possible. Everyone now supports that "defacto" standard and eventually it is documented as "the standard" by some committee. Route 2 usually results in better software and more rapid innovation.
This is particularly relevant to XmlHttpRequest. It was originally an IE only extension and the rest of the browser world said "Wow, that's cool". Soon it showed up in all the other browsers (without the need for ActiveX on which IE's XmlHttpRequest is based).
It might be worthwhile to implement support for multipart/x-mixed-replace in WebKit in a manner compatible with Firefox's and then push for that to become the standard with the appropriate group.
Personally I think supporting this is really important. I might even try and hack a patch together.
May be related to Bug 14149.
EventSource is now available in WebKit (and proposals to standardize support for any of the multipart/* flavors were few, and never got enough attention to be added to XMLHttpRequest).
I have to agree with Rob. EventSource implementation is a disaster. Besides poor design, it has memory leaks and cannot be used from Java: http://code.google.com/p/chromium/issues/detail?id=66666
It is obvious that it was not tested very well.
I cannot imagine anyone would prefer EventSource to the multipart/x-mixed-replace.
is there any news about this issue?
FF has this option since a long time... https://bugzilla.mozilla.org/attachment.cgi?id=144021&action=diff
Thanks a lot