Re: [XHR] chunked

On Wed, Nov 30, 2011 at 7:28 AM, Anne van Kesteren <annevk@opera.com> wrote:

> A while ago sicking proposed adding chunked support to XMLHttpRequest:
>
> http://lists.w3.org/Archives/**Public/public-webapps/**
> 2011JulSep/0741.html<http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html>
> https://bugzilla.mozilla.org/**show_bug.cgi?id=687087<https://bugzilla.mozilla.org/show_bug.cgi?id=687087>
>
> A use case I remember was downloading a large file of some kind that
> presumably can be incrementally rendered as otherwise responseType "blob"
> should be sufficient. More use cases appreciated. Would help with the
> design.
>
E.g. voice/image search, translation ... IMHO any single resource that
involves non-trivial processing to produce would fit the use case.


>
> As for the feature, basically have responseType "chunked-text" and
> "chunked-arraybuffer" values and reset rather than update the response
> entity body with each progress event. And make sure that a progress event
> is dispatched when the last fetch event is queued. And make sure that this
> is only available for asynchronous usage.
>
> Charles asked whether "chunked-text" was really needed (and whether we
> should have "chunked" which implies ArrayBuffer instead). Nobody got back
> to him on that. If it is needed, how does it work when you just have some
> of the bytes of a multi-byte character in a single chunk? Fails to decode
> as per the normal algorithm?
>
When text is consumed as chunked streams, my take is that the application
code has to deal with partial frames, and partial chars are just one
sub-problem. So, I wouldn't consider multi-byte characters a particular
limitation.


>
> Also, this basically makes it possible to write EventSource on top of
> XMLHttpRequest. Is that acceptable? If it encourages more people to use a
> lower-level API, higher-level optimizations for mobile phones might become
> harder down the road.
>
At the same time, lower-level APIs that match the underlying wire-protocol
(i.e. HTTP) would be equally important for optimization purposes.

Thanks,
Wenbo

>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>