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

On Tue, Mar 30, 2010 at 11:30 PM, Pablo Castro
<Pablo.Castro@microsoft.com>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?
>

That sounds perfect.