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

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.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?

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.

Received on Tuesday, 30 March 2010 22:55:01 UTC