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

That sounds great to me.

On Thu, Aug 12, 2010 at 10:55 AM, Andrei Popescu <andreip@google.com> wrote:

> On Thu, Aug 12, 2010 at 6:54 PM, Andrei Popescu <andreip@google.com>
> wrote:
> > 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
> >
>
> Sorry, I meant PositionOptions:
>
> http://dev.w3.org/geo/api/spec-source.html#position-options
>
> Andrei
>