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

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:
>
>
> >> 6) The specific ordering of elements should probably be specced
> including a mix of types.
> >>
> >> Can you propose spec text for this? What do you think about the text in
> http://www.w3.org/TR/IndexedDB/#key-construct?
> >>
> >> If we're only adding long long for v1, then I think language similar to
> what's there now is probably OK.  But now that I think about it, I'm a bit
> concerned that we might be backing ourselves into a corner for the future.
>  I also noticed that the sort order of JavaScript seems to order it numbers,
> strings, and then nulls (not strings, numbers, nulls).
>
> >> I wonder if there is some other spec on sort order we can cite rather
> than rolling our own.
>
> I really think that just doing long/strings won't do, even for v1. For
> non-primary-key indexes we'll need at least Date and number (not just
> integers) in addition to long/string. Without that there is no ordering by
> "date sent" for emails or "list price" for products or lots of other
> scenarios where you're caching data coming from a server.
>
>
> >> 2) What happens when data mutates while you're iterating via a cursor?
> >>
> >> This is covered by http://www.w3.org/TR/IndexedDB/#dfn-mode
> >>
> >> That applies to two separate transactions.  As far as I can tell, it
> should be possible to have a cursor open and then delete an element that the
> cursor is currently traversing all within the same transaction.  Am I
> missing something?
>
> I was assuming that within the same transaction you could change rows and
> those changes would be observable from open cursors. If it happens to be the
> current row then you won't be able to fetch it anymore but you can still
> move to the next one and continue scanning (and seeing any new changes that
> happened since you last moved).
>
>
> >> 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).