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

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

From: Andrei Popescu <andreip@google.com>
Date: Thu, 12 Aug 2010 18:54:24 +0100
Message-ID: <AANLkTin+EdX6HOSoMCWMvS2o8awKEb_m506mn_ufAw73@mail.gmail.com>
To: Pablo Castro <Pablo.Castro@microsoft.com>
Cc: Jeremy Orlow <jorlow@chromium.org>, Jonas Sicking <jonas@sicking.cc>, Shawn Wilsher <sdwilsh@mozilla.com>, Webapps WG <public-webapps@w3.org>
On Thu, Aug 12, 2010 at 6:28 PM, Pablo Castro
<Pablo.Castro@microsoft.com> wrote:
> 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.

This is fine with me.

> The only thing I'm not sure is if there is precedent of doing this in one of the standard APIs.

There is: http://dev.w3.org/geo/api/spec-source.html#position_interface

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC