- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 9 Sep 2009 12:49:07 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: WebApps WG <public-webapps@w3.org>
On Wed, Sep 9, 2009 at 10:48 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Wed, 09 Sep 2009 19:41:38 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Wed, Sep 9, 2009 at 7:14 AM, Anne van Kesteren <annevk@opera.com>
>> wrote:
>>>
>>> I believe it is the idea that Web Sockets will support sending and
>>> receiving structured clones. It might make sense to define that format
>>> sooner rather than later so implementations of Web Storage that support
>>> structured clones can use it.
>>
>> HTML5 already defines which objects can be "strucurally cloned". This
>> is enough for webstorage. What remains to be defined if structured
>> clones can be sent over websocket is to define a serialized format.
>> However webstorage does not need such a serialized format as far as I
>> can tell.
>
> It does not need to expose it, but you do need to serialize to something as
> far as I can tell if you write it to disk.
Yes, you need to serialize. But you can serialize using whatever
format you want for web storage.
> If the format for Web Sockets is
> clear maybe we have to only worry about the serialization of structured
> clones once.
True, once an implementation writes the code for websockets you could
then reuse that for localStorage. However there is a good reason not
to. Say that someone stores an object like:
{
hello: "bar",
theFile: myFile
}
where 'myFile' is a File object. In this case you'll probably want to
store the file object separately. This way when data is read out of
localStorage, you won't need to read in the file data. Instead you
just serialize a pointer to where the file data is stored, and then
when deserializing, create a File object that reads (asynchronously)
from that location.
/ Jonas
/ Jonas
Received on Wednesday, 9 September 2009 19:50:07 UTC