- From: Marcos Caceres <marcosc@opera.com>
- Date: Wed, 16 Sep 2009 09:36:43 +0200
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-webapps <public-webapps@w3.org>
On Wed, Sep 16, 2009 at 2:20 AM, Ian Hickson <ian@hixie.ch> wrote: > 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. I know that (well, the DOM is serialized as HTML or XHTML markup;)). My question was: does a serialization of structured clones needs to be specified? If "no", why not? >> 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. Understood. This is our current approach. >> 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. Ok, that makes good sense. We will evaluate which behavior suits us best, and copy the appropriate bits from either localStorage or sessionStorage. Thanks for your help and time! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Received on Wednesday, 16 September 2009 07:37:49 UTC