Andrew, this is a neat idea but from my knowledge it is not currently applicable to HTML fragments to be inserted in the DOM.
"Transfer-encoding: chunked" means that "output_buffering" is enabled on the server. Each chunk size is predefined (configurable), normally the default in PHP is set to 4Kbytes but could be made smaller or larger, the configuration in PHP may be changed by means of the "output_buffering" directive. Here are the relevant commented lines from my "php.ini": ; Output buffering allows you to send header lines (including cookies) even ; after you send body content, at the price of slowing PHP's output layer a ; bit. You can enable output buffering during runtime by calling the output ; buffering functions. You can also enable output buffering for all files by ; setting this directive to On. If you wish to limit the size of the buffer ; to a certain size - you can use a maximum number of bytes instead of 'On', as ; a value for this directive (e.g., output_buffering=4096). output_buffering = On The problem is that for HTML we have to insert the fragment in the DOM and to do that we need to know where the HTML tags starts and where they end, we could not insert a "chunk" like this one: <div>Test example <strong>Reults (no closing tag has arrived in the last chunk, so broken HTML) Yes that's what can happen, since the chunks have a predefined length we have no way to know the size in advance from the client-side, maybe something could be done server-side to mitigate this problem with HTML data (some wrapper/parser). If the data has no structure, and can be rendered or used byte by byte then maybe this idea has a bright future. I confirm that "Transfer-encoding: chunked" is not MXHR (Multi-part XHR) like in DUI.Stream, it is just a mean of transferring long streams of data in chunks as the answer to a single HTTP request. And yes if feasible it will perform better than MXHR since the multi-part headers and related TCP overhead will be avoided both sides and Cookies will be sent only once in the first and only XHR. +1 for the idea, keep us informed on the development. Diego PS: "Transfer-encoding: chunked" and browser local caching is what makes our life difficult in detecting the DOMContentLoaded event in IE. In fact in this mode the client has no way of knowing in advance the length of the answer, if transfer is chunked there will not be a "Content-Length: xxxx" header in the answer. On 30 Mag, 22:26, Andrew Ingram <[email protected]> wrote: > I'm talking about content-encoding: chunked, it's a single connection. > The server can periodically 'flush' the response stream to send all > content that has been generated up to that point. The idea being that > if each chunk is self-contained, ie a single entity on a response that > would return a list of entities, the AJAX library can handle the first > entities before the complete response has even finished being > generated by the server. > > Technically this could require even less connection overhead than > Comet because you could keep the connection open after delivering each > 'update' - rather than requiring the client to create a new connection > each time. > > http://en.wikipedia.org/wiki/Chunked_transfer_encoding > > Now I could be completely mistaken and actually chunked encoding > requires multiple connections, but I don't believe this to be the > case. > > On May 30, 3:31 pm, Ricardo <[email protected]> wrote: > > > Creating lots of connections would probably have a large overhead > > making it slower than if you waited for the whole processing to end, > > for each connection you have to factor the 2-way latency + server > > response time. A better approach and already usable is HTTP Streaming/ > > Comet: > > >http://ajaxpatterns.org/HTTP_Streaming > > > On May 29, 7:36 pm, Andrew Ingram <[email protected]> wrote: > > > > Hi all, > > > > I'm not even sure if this is possible with JavaScript at the moment, > > > but it would make a powerful feature if it were. > > > > If returning a list of resources as the response to a request, it's > > > relatively trivial to configure the app (in Django at least) to flush > > > the stream after each resource and provide a semi real-time feed of > > > results, ie you don't have to wait for the last item to be calculated > > > before the first one is returned. This uses Content-Encoding chunked. > > > > I was thinking that if jQuery could somehow recognise these types of > > > response, it could iterate over these individual resources as they > > > come over the wire, then the callback would be given individual items > > > rather than the full response. This would make AJAXy functionality > > > even more responsive because you can start handling parts of the > > > response before the server has even finished generating the later > > > parts. > > > > Maybe this is already possible, but I couldn't have any documentation > > > or mention of it. > > > > Any thoughts on this idea? > > > > Regards, > > > Andrew Ingram --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
