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

On Mon, Aug 9, 2010 at 11:36 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Mon, Aug 9, 2010 at 11:31 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Mon, Aug 9, 2010 at 3:24 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
>> > On Mon, Aug 9, 2010 at 11:15 PM, Andrei Popescu <andreip@google.com>
>> > wrote:
>> >>
>> >> On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow <jorlow@chromium.org>
>> >> wrote:
>> >> > I'm pretty sure opening a database with a different description is
>> >> > actually
>> >> > already specified: the new one takes precedent.  Take a look at the
>> >> > algorithm for database opening; I'm pretty sure it's there.
>> >> > When talking to Andrei earlier tonight I thought we'd probably want
>> >> > to
>> >> > make
>> >> > it optional, but now I'm thinking maybe we shouldn't.  You're right,
>> >> > Shawn,
>> >> > that the description can be useful for many reasons.  And although it
>> >> > seems
>> >> > redundant for a developer to pass in the description every time, I
>> >> > actually
>> >> > can't think of any reason why a developer wouldn't want to.
>> >>
>> >> Actually, I think it's pretty inconvenient to have to specify a
>> >> description every time, especially since I am not sure developers
>> >> would want to change the description very often. I think we should
>> >> allow a null string for future connections as Shawn suggested.
>> >
>> > How do developers distinguish between when they're opening a database
>> > for
>> > the first time or not?  Normally they'd look at the version, but that's
>> > not
>> > available until _after_ you've supplied the description (and presumably
>> > some
>> > UAs might have asked the user if it's OK or something like that).  If
>> > the
>> > spec has a way to enumerate databases (something we've talked about
>> > doing)
>> > then it's possible that the developer could decide whether or not to
>> > pass in
>> > a version string that way.  But why would they do this?
>> > So the only possible reason I could see for someone doing this is if
>> > they
>> > open a database in several places in one page and they can
>> > somehow guarantee that one of them happens first.  The first question
>> > here
>> > would be "but why?".  And the second question is whether we trust users
>> > to
>> > for sure know the ordering that things are opened.
>> > On the other hand, it doesn't seem that hard to supply a description
>> > every
>> > time it's opened.  I mean you just define it in one places within your
>> > script and use that.  Or, better yet, just save the database to a
>> > variable
>> > and call open once early on in initialization.  That'll make things less
>> > async anyway.
>> > Am I missing something here?
>>
>> I have actually been thinking that it's likely fairly common to be
>> opening a database in several different locations and know which ones
>> should always be reopening an existing database.
>>
>> I don't have any data on this though.
>
> Neither do I.
> Well, if we make it optional based on the assumption this is true, maybe we
> could spec it such that opening a database for the first time with no
> description is an error?
> Or we just remove description all together if it's not going to
> be dependable?

Thinking more about it, do we really want this string to be displayed
to the user? What happens if the browser is using one locale and the
string is in another? To me, the description is something internal to
the application, not something intended for the end-user. I think we
should remove it altogether if we don't have a good use case for it.

Thanks,
Andrei

Received on Tuesday, 10 August 2010 10:31:20 UTC