MXHR

Digg is creating a multipart capable XHR library. Good try but not very useful. Here is why:

1. MXHR response is not compressed by default.
   This is illustrated very well in their text only demo. MXHR stream is always slower than normal mode. I opened up the packet sniffer. The normal stream is compressed while the MXHR is not.
   
2. Data URI scheme is broken.
   The web is broken by IE for a long time. IE6 and IE7 will be still around for a few years. Image data cannot be served in cross-browser manner. The same performance can be achieved by spriting: putting the tiny-images into one image (overhead is small if the image is large enough), preload the combined imaged, and use background-position to get the coordination.
   
3. Multipart is not streaming
   Well, it is under DUI.Stream namespace. However, it is not streaming. The server is packing up the data into one response. The library is processing the data on-the-fly but the received data is accumulating.
   1. If the size of the response is not large (i.e. can be stream in a couple seconds), enveloping the message in JSON or XML could be easier.
   2. If the size of the response is large (i.e. comet style), the responseText is going to become very large. We call it memory leak.
   

HTTP is broken because it is not intended to serve for Web 2.0. That's why there are so many facilities in CSS and JavaScript to patch the protocol. MXHR is definitely not the answer.