RE: [IndexedDB] Lots of small nits and clarifying questions

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?

-pablo

Received on Tuesday, 30 March 2010 22:31:02 UTC