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

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.

/ Jonas

Received on Monday, 9 August 2010 22:32:34 UTC