[Webkit-unassigned] [Bug 14392] Add support for multipart/x-mixed-replace to XMLHttpRequest

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=14392





------- Comment #3 from crodster2k at yahoo.com  2007-06-26 08:09 PDT -------
(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.

I have a problem with overloading the DOM event system to support server
interaction.  Conceptually, it's a nice feature because there is a single
system for handling "events" from the client or server.  But that is where the
benefits end.  Anything fired within the DOM event loop takes time away from UI
responsiveness.  Normally JavaScript is only single threaded, but with
developments like Google Gears there is now some support for multiple threads
and background tasks.  This allows the UI to remain responsive.

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.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.