W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2009

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

From: Preston L. Bannister <preston@bannister.us>
Date: Tue, 10 Nov 2009 22:38:26 -0800
Message-ID: <7e91ba7e0911102238g305f7d66hd35844f6ec46cccd@mail.gmail.com>
To: public-script-coord@w3.org
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.

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:

   1. Raw disk read from server disk, and shipped without interpretation to
   the client.
   2. Web connections to legacy services that only chat using only non-HTML
   binary data.

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.

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.
Received on Wednesday, 11 November 2009 06:39:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:02 UTC