Re: What is the use-case for binary data in client-side script?

On Nov 10, 2009, at 10:38 PM, Preston L. Bannister wrote:

> First, I have to admit to not tracking every prior possibly-relevant  
> discussion. I do not have that much free time. So I may be missing  
> from context. (Did search through past discussions, looking for  
> context.) Yes, I am stepping late into this discussion.
>
> Javascript is a nice higher-order language. Web browsers have rich  
> knowledge of objects exchanged across HTTP.  I would hope and expect  
> Javascript in the web browser to "know" generally about the objects  
> known to a web browser, and be able to manipulate those objects,  
> within the capabilities of the web browser.
>
> On Wed, Nov 4, 2009 at 4:26 PM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>
> Many APIs being developed for the Web platform would benefit from a  
> good way to store binary data. It would be useful for this to be  
> specified as part of the ECMAScript language, but it's also  
> plausible to make this a W3C spec that's only intended for use with  
> Web platform APIs. Here is an overview of some of the APIs that  
> could use such a data type, some notes on requirements and design  
> alternatives, and a strawman proposal.
>
>
> What is not clear to me is whether binary data has any place in  
> client-side Javascript. Strictly speaking, there is no such thing as  
> binary data. Binary data is just a serialized representation of an  
> object. I would greatly prefer that object serialization and de- 
> serialization occur in the native code of the web browser, and not  
> in Javascript (both for efficiency, and brevity in script). If the  
> object in question is one of a kind known to the web browser, I  
> would hope to leverage the web browser code.

That's an appealing approach, when it is practical. But there's two  
important limitations:

1) There's binary file formats that are not natively understood by the  
browser. I think it would be short-sighted to say that a Web client  
just can't work with those. For example, bz2 compression is pretty  
neat, and it seems like it would be cool to be able to do that on the  
client.

2) Sometimes the browser's built-in processing capabilities don't  
match what you want to do in client-side code. For example, Safari has  
native PDF viewing capability, but what if you want to find the text  
strings in a PDF file and make a searchable index? Then the browser's  
native processing doesn't help. Similarly, we'll happily un-gzip  
content that's sent using HTTP gzip compression, but that does not  
help you if you have a .gz file.

3) Sometimes the goal is not to interpret binary data on the client  
side, but simply to transfer it elsewhere, perhaps after some minimal  
processing. For example, you may want to store a binary file in local  
storage, then chop it into pieces and upload to a server one chunk at  
a time.

4) Even some forms of text manipulation are at some level binary-like,  
for example, character set transcoding. There's not even a good way to  
support transcoding without some way to handle the input or output as  
binary.

>
> In the browser, mime-types generally define object-classes. A "text/ 
> html" object might be a DOM-tree, or a string. A "text/json" object  
> might be a Javascript object, or a string. An "image/jpeg" object is  
> a jPEG image, hopefully with methods and attributes reflective of  
> the web browser's understanding of a JPEG image.
>
> I am somewhat ambivalent about supporting arbitrary serialization  
> and deserialization in client-side Javascript. I am not fond of the  
> notion of byte-oriented serialization/deserialization in Javascript  
> code. Maybe there is a compelling use-case for this sort of usage,  
> but I am inclined to be dubious.
>
> The only use-cases that come to mind are:
> Raw disk read from server disk, and shipped without interpretation  
> to the client.
> Web connections to legacy services that only chat using only non- 
> HTML binary data.
There's also handling of binary data in a format not understood by the  
client. Perhaps the client-side JavaScript is patching over missing  
browser capabilities, or the Web app has invented a new binary format  
itself.
> Personally, in both cases I would (for a number of reasons) choose  
> to do the interpretation on the server, and only ship web-browser- 
> friendly objects to the client.

Even to transfer binary data to the server requires a form to  
represent it. But beyond that, it seems to me that not all Web  
developers share your preference, and there is no obvious harm from  
meeting their use cases.

> I am not sure there should be a use-case for binary data in client- 
> side Javascript.
>
> On the flip side, I seem to have missed the discussion of mime-type  
> object support, and the methods and attributes mapped to such objects.


I'm not sure what you mean by "mime-type object". Would you like to  
clarify?

Regards,
Maciej