Re: [whatwg] asynchronous JSON.parse

Le 08/03/2013 22:16, David Rajchenbach-Teller a écrit :
> On 3/8/13 5:35 PM, David Bruant wrote:
>>> 2. serialize JSON (hopefully asynchronously) to a Transferable (or
>>> several Transferables).
>> Why not collect the data in a Transferable like an ArrayBuffer directly?
>> It skips the additional serialization part. Writing a byte stream
>> directly is a bit hardcore I admit, but an object full of setters can
>> give the impression to create an object while actually filling an
>> ArrayBuffer as a backend. I feel that could work efficiently.
> I suspect that this will quickly grow to either:
> - an API for serializing an object to a Transferable or a stream of
> Transferable; or
> - a lower-level but equivalent API for doing the same, without having to
> actually build the object.
Yes. The difference with JSON is that it can be transfered directly 
without an extra step.

Whether you put the info in an Object as properties (before being 
JSON.stringify()'ed) or directly in a Transferable, the snapshot info 
needs to be stored somewhere.


> For instance, how would you serialize something as simple as the following?
>
> {
>    name: "The One",
>    hp: 1000,
>    achievements: ["achiever", "overachiever", "extreme overachiever"]
>     // Length of the list is unpredictable
> }
If it's possible to serialize this as a string (like in JSON), it's 
possible to serialize it in an ArrayBuffer.
Depending on implementations, serializing a list will require to define 
separators or maybe a length field upfront, etc. But that's doable.

Taking a second for an aside.
I've once met someone who told me that JSON was bullshit. Since the guy 
had blown my mind during a presentation, I've decided to give him a 
chance after this sentence :-p He explained that in JSON, a lot of 
characters are double quotes and commas and brackets. Also, you have to 
name fields.
He said that if you want to share 2 ints (like longitude and latitude), 
you probably have to send the following down the wire:
     '{"long":12.986,"lat": -98.047}'
which is about 30 bytes... for 2 numbers. He suggested that a client and 
server could send only 2 floats (4 bytes each, so 8 bytes total) and 
have a convention as to which number is first and you'd just be done 
with it.
30 bytes isn't fully fair because it could be gzipped, but that takes 
additional processing time in both ends.

He talked about a technology he was working on that, based on a message 
description would output both the client and server code (in different 
languages if necessary) so that whatever message you send, you just 
write your business code and play with well-abstracted objects and the 
generated code takes care of the annoying "send/receive a 
well-compressed message" part.

That was an interesting idea.

Back to your case, it's always possible to represent structured 
information in a linear array (hence filesystems, hence databases).

David

Received on Saturday, 9 March 2013 19:22:11 UTC