On Tue, March 30, 2010 at 2:53 AM, Jeremy Orlow wrote: >> On Tue, Mar 30, 2010 at 9:10 AM, Pablo Castro <pablo.cas...@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 <nik...@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? -pablo
