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
