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

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

Received on Thursday, 23 June 2011 13:50:54 UTC