W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

RE: [IndexedDB] question about description argument of IDBFactory::open()

From: Pablo Castro <Pablo.Castro@microsoft.com>
Date: Thu, 12 Aug 2010 17:28:20 +0000
To: Jeremy Orlow <jorlow@chromium.org>, Jonas Sicking <jonas@sicking.cc>
CC: Andrei Popescu <andreip@google.com>, Shawn Wilsher <sdwilsh@mozilla.com>, Webapps WG <public-webapps@w3.org>
Message-ID: <F753B2C401114141B426DB383C8885E05901BB9A@TK5EX14MBXC126.redmond.corp.microsoft.com>

From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Jeremy Orlow
Sent: Thursday, August 12, 2010 3:59 AM

>> On Thu, Aug 12, 2010 at 11:55 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
>> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349
>> > One quesiton though: if they pass in null or undefined, do we want to
>> > interpret this as the argument not being passed in or simply let them
>> > convert to "undefined" and "null" (which is the default behavior in WebIDL,
>> > I believe).  I feel somewhat strongly we should do the former.  Especially
>> > since the latter would make it impossible to add additional parameters to
>> > .open() in the future.
>> I don't understand why it would make it impossible to add optional
>> parameters in the future. Wouldn't it be a matter of people writing
>> indexeddb.open("mydatabase", "", SOME_OTHER_PARAM);
>> vs.
>> indexeddb.open("mydatabase", null, SOME_OTHER_PARAM);
>> So "" is assumed to mean "don't update"?  My assumption was that "" meant empty description.
>> It seems silly to make someone replace the description with a space (or something like that) if they truly want to zero it out.  And it seems silly to ever make your description be >> "null".  So it seemed natural to make null and/or undefined be such a signal.

Given that open() is one of those functions that are likely to grow in parameters over time, I wonder if we should consider taking an object as the second argument with names/values(e.g. open("mydatabase", { description: "foo" }); ). That would allow us to keep the minimum specification small and easily add more parameters later without resulting un hard to read code that has a bunch of "undefined" in arguments. The only thing I'm not sure is if there is precedent of doing this in one of the standard APIs.

Received on Thursday, 12 August 2010 17:28:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:35 UTC