Re: [WebStorage] structured clones serialization

On Mon, 14 Sep 2009, Marcos Caceres wrote:
>
> With the recent move to structured clones in Web Storage, I'm
> wondering if a serialization for those clones needs to be specified?

Nothing in HTML5 exposes a serialisation.


> A use case for widgets is widget preferences, where the preference's in 
> a widget's configuration document are used to populate a storage object. 
> At the moment, we only support strings:
> 
> <widget ...>
>   <preference name="foo" value="bar"/>
> </widget>
> 
> Becomes:
> 
> window.widget.preferences.foo;
> 
> However, enabling some kind of text-based serialization for 
> structured-clones would allow authors to serialize more complex data.

I recommend using JSON, though it doesn't allow everything to be 
expressed that can be cloned.


> Some other comments for the current editor's draft:
> 
> I wonder if, where there is overlap, the following two assertions
> could be merged into a general assertion applied to the an object that
> implements Storage (as it would be useful for widgets.preferences).
> 
> [[
> 4.2 The sessionStorage attribute
> User agents should expire data from the local storage areas only for
> security reasons or when requested to do so by the user. User agents
> should always avoid deleting data while a script that could access
> that data is running.
> 
> 4.3 The localStorage attribute
> User agents should not expire data from a browsing context's session
> storage areas, but may do so when the user requests that such data be
> deleted, or when the UA detects that it has limited storage space, or
> for security reasons. User agents should always avoid deleting data
> while a script that could access that data is running. When a
> top-level browsing context is destroyed (and therefore permanently
> inaccessible to the user) the data stored in its session storage areas
> can be discarded with it, as the API described in this specification
> provides no way for that data to ever be subsequently retrieved.
> ]]

There seems to be very little overlap; I'm not sure there's enough to 
really justify a separate section. (For example, if we were to remove the 
bit about security reasons for deleting data, I wouldn't bother putting it 
into a common section, I'd just remove it altogether. It doesn't really 
add much, the only reason I included it was completeness so that people 
reading the above paragraphs didn't think I was trying to override UA 
decisions on security.)

Because each type of storage area can have its own rules, I recommend 
having a separate paragraph for each one. It's possible for Storage 
objects to be volatile to the point where items can be deleted while 
script is running, that's a decision for whatever spec uses it.


> In the spec it sez:
>   "The use of parseInt() is needed when dealing with numbers (integers
> in this case) because the storage APIs are all string-based."
> 
> Is the above still true with the introduction of structured clones?

Fixed.


> In the spec it sez:
>   "Storage areas (both session storage and local storage) store
> strings. To store structured data in a storage area, you must first
> convert it to a string."
> 
> As above. I'm all for casual language in a spec (makes it fun to read!), 
> but "you" should really make it clear that it's the author and not the 
> UA that needs to do the conversion.

It's gone now, since it's no longer true.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 16 September 2009 00:15:34 UTC