- From: Nikunj Mehta <nikunj@o-micron.com>
- Date: Tue, 30 Mar 2010 15:54:10 -0700
- To: Pablo Castro <Pablo.Castro@microsoft.com>
- Cc: Jeremy Orlow <jorlow@chromium.org>, public-webapps WG <public-webapps@w3.org>, Andy Palay <ajpalay@google.com>
On Mar 30, 2010, at 3:30 PM, Pablo Castro wrote: > On Tue, March 30, 2010 at 2:53 AM, Jeremy Orlow wrote: > >>> On Tue, Mar 30, 2010 at 9:10 AM, Pablo Castro <Pablo.Castro@microsoft.com >>> > wrote: >>> Sorry for having disappeared for a while, "odata" was keeping me >>> busy. I agree with all the clarifications listed in this thread >>> that are required, so I won't redundantly mark each with "same >>> here", but I have a few comments on one or two of them below. > >>> On Mon, Mar 15, 2010 at 8:14 AM, Jeremy Orlow wrote: > >>> On Sat, Mar 13, 2010 at 9:02 AM, Nikunj Mehta <nikunj@o- >>> micron.com> wrote: >>> Thanks for your patience. Most questions below don't seem to need >>> new spec text. > >>> On Feb 18, 2010, at 9:08 AM, Jeremy Orlow wrote: > >>>>> 1) Structured clone is going to change over time. And, >>>>> realistically, UAs won't support every type right away anyway. >>>>> What do we do when a value is inserted that we do not support? > >>>>> We will evolve the text as and when the same evolves in >>>>> WebStorage. > >>>>> I don't know of any implementations which have moved away from >>>>> only allowing strings within WebStorage. I suspect that not >>>>> fully supporting the structured clone algorithm as specced is >>>>> one of the reasons for this. > >>>>> As far as I can tell, you're essentially saying that fully >>>>> supporting the the structured clone algorithm a pre-req for >>>>> IndexedDB? I guess I can't argue too much with that, but I'm >>>>> not sure how realistic it is. I know we only half support it at >>>>> the moment in Chromium. > I have the same worry about structured clones...it's right in > principle but I can't see implementations converging and that will > just hurt interoperability. Unfortunately there doesn't seem to be a > well-known middle-ground. JSON is way too restrictive (e.g. no > Date). Should we consider defining a subset of structured clones > that work (maybe something like Javascript primitives plus Date plus > whatever extra we feel we should include such as perhaps File > objects)? > >>> There is some precedent for what you suggest: the spec for >>> LocalStorage already specifies that storing ImageData isn't >>> allowed. (http://dev.w3.org/html5/webstorage/#the-storage- >>> interface see setItem section.) > >>> On the other hand, I'm not sure I like the idea of each API >>> supporting different subsets of the structured clone algorithm. >>> Even if all UAs support the same subset for each API, it still >>> seems fairly confusing to web developers. And I'm guessing that >>> UAs won't be to keen on adding more complex control flow to their >>> structured clone implementations to disallow different parts of >>> the algorithm based on what it's using. Thus any specced subset >>> of the algorithm will probably need to be a MAY not a MUST. > >>> I still think we should spec an error to be returned when the UA >>> doesn't fully support the structured clone algorithm and thus >>> can't handle the data provided. I agree it's sub-optimal, but I >>> think it's the pragmatic choice. Especially if the structured >>> clone algorithm ever changes (and thus implementations can fall >>> out of compliance with the spec). > > I agree with that concern, but I also worry that we'll end up with > UAs implementing different subsets and then developers having to > settle for the minimum common denominator or doing a bunch of guess > work. May be we use structured clone but have some non-normative > text that recommends reasonable subset that we can agree are > something we can all implement consistently? In this case, the non-normative text is really tracking status update of structured clone implementation. If so, I don't see a problem with that. On the other hand, it does not make sense to put in "normative spec" as non-normative text in the spec.
Received on Tuesday, 30 March 2010 22:55:01 UTC