On Mar 30, 2010, at 3:30 PM, Pablo Castro 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.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?
In this case, the non-normative text is really tracking status update
of structured clone implementation. If so, I don't see a problem with
that. On the other hand, it does not make sense to put in "normative
spec" as non-normative text in the spec.