- From: Pablo Castro <Pablo.Castro@microsoft.com>
- Date: Tue, 30 Mar 2010 08:10:29 +0000
- To: Jeremy Orlow <jorlow@chromium.org>, Nikunj Mehta <nikunj@o-micron.com>
- CC: public-webapps WG <public-webapps@w3.org>, Andy Palay <ajpalay@google.com>
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)? Thanks -pablo
Received on Tuesday, 30 March 2010 08:11:13 UTC