Re: [XHR] chunked

On Nov 30, 2011, at 11:32 AM, Jonas Sicking <jonas@sicking.cc> wrote:

>> 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.
> 
> Any text based format would benefit from chunked-text. While the
> example above uses a binary format, it applies equally to text based
> formats. And given how much we in this group seem to prefer text based
> formats, (HTML, CSS, Javascript, EventSource, JSON) I think we should
> assume that other people at least use them, if not prefer them.

My thinking was that ArrayBuffer can easily be converted to String by authors. Even with text-based formats, I prefer to fetch data as blob and buffer.


> 
>> 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?
> 
> Any multi-byte characters which are only partially downloaded are not
> returned in that "chunk". I.e. you only expose fully decoded
> characters. The value in progressEvent.loaded doesn't match up with
> the accumulated xhr.response.length for multi-byte encodings anyway.


This is an interesting case and may be a good reason to have a chunked text type.

When I'm parsing streams, I'm going to be waiting on various delimiters, and appending unprocessed bits... So the multibyte issue won't be an issue for me. Consider in any XML format, the developer is going to be seeking closing tags, or such.

But, getting the behavior you're looking for, where the callback is ensured that the string has full multibyte characters, that's not particularly easy for developers. While I wouldn't use it, as I'd use chunked arraybuffer, I can see how it'd be useful to achieve those parameters. There are various APIs that expect valid DOMString.

Received on Wednesday, 30 November 2011 20:13:49 UTC