Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null

Cheers!

On 6/23/11, Mark Pilgrim <pilgrim@google.com> wrote:
> On Sun, Jun 19, 2011 at 2:35 AM, Adam Barth <w3c@adambarth.com> wrote:
>> On Mon, Jun 13, 2011 at 9:40 AM, Adam Barth <w3c@adambarth.com> wrote:
>>> On Mon, Jun 13, 2011 at 1:31 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>> On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth <w3c@adambarth.com> wrote:
>>>>> On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking <jonas@sicking.cc>
>>>>> wrote:
>>>>>> On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack <cam@mcc.id.au>
>>>>>> wrote:
>>>>>>> Adam Barth:
>>>>>>>> > WebKit is looser in this regard.  We probably should change the
>>>>>>>> > default for new IDL, but it's a delicate task and I've been busy.
>>>>>>>> >  :(
>>>>>>>
>>>>>>> What about for old IDL?  Do you feel that you can make this change
>>>>>>> without breaking sites?  One of the “advantages” of specifying the
>>>>>>> looser approach is that it’s further down the “race to the bottom”
>>>>>>> hill,
>>>>>>> so if we are going to tend towards it eventually we may as well jump
>>>>>>> there now.
>>>>>>
>>>>>> I can't remember getting a single bug filed on Geckos current
>>>>>> behavior. There probably have been some which I've missed, but it's
>>>>>> not a big enough problem that it's ever been discussed at mozilla as
>>>>>> far as I can remember.
>>>>>
>>>>> Unfortunately, there's a bunch of WebKit-dominate content out there
>>>>> that folks are afraid to break.  We discussed this topic on some bug
>>>>> (which I might be able to dig up).  The consensus was that the value
>>>>> in tightening this for old APIs wasn't worth the compat risk (e.g., in
>>>>> mobile and in Mac applications such as Dashboard and Mail.app).
>>>>>
>>>>> For new APIs, of course, we can do the tighter things (which I agree
>>>>> is more aesthetic).  It mostly requires someone to go into the code
>>>>> generator and make it the default (and then to special-case all the
>>>>> existing APIs).  I'd like to do that, but it's a big job that needs to
>>>>> be done carefully and I've got other higher priority things to do, so
>>>>> it hasn't happened yet.
>>>>
>>>> If there is agreement that new APIs should throw for omitted
>>>> non-optional parameters, then it seems clear that WebIDL should use
>>>> that behavior.
>>>>
>>>> That leaves the work for safari (and possibly other webkit devs) to go
>>>> through and mark parameters as [optional] in their IDL. Possibly also
>>>> filing bugs for cases where you want the relevant spec to actually
>>>> make the argument optional. I realize that this is a large amount of
>>>> work, but this is exactly what we have asked in particular of
>>>> microsoft in the past which has been in a similar situation of large
>>>> divergence from the DOM specs, and large bodies of existing content
>>>> which potentially can depend on IE specific behavior.
>>>
>>> Think folks are agreed that's the path we should follow.  My only
>>> concern is that we don't have anyone signed up to do the work on the
>>> WebKit side.
>>
>> Just to update this thread, Mark Pilgrim has stepped forward to get
>> the ball rolling on this work, so WebKit is making progress on this
>> front.
>
> I'm happy to report that WebKit's implementation of IndexedDB now
> follows WebIDL and throws TypeError on all functions when called with
> missing required arguments. We have grandfathered in all existing IDL
> files to use the old, looser code generator, but we are actively
> working on migrating *all* 521 IDL files to use the new, stricter
> generator (with [Optional] flags in places where we can't break
> compatibility). IndexedDB is the first success in this process; as an
> experimental API, we feel no need to maintain compatibility and have
> opted for the stricter semantics everywhere, matching the WebIDL and
> IndexedDB specs exactly. Next will be other experimental APIs like the
> web audio API and the File API, where we hope to have similar levels
> of success.
>
> -Mark
>
>

-- 
Sent from my mobile device

Received on Friday, 24 June 2011 02:21:54 UTC