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

On Wed, Aug 11, 2010 at 11:50 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Tue, Aug 10, 2010 at 12:26 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
>>
>> On Tue, Aug 10, 2010 at 11:30 AM, Andrei Popescu <andreip@google.com>
>> wrote:
>>>
>>> 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.
>>
>> Also there are security concerns.  For example, it'd be hard to use the
>> description in a useful way without trusting what it says.  Which isn't
>> always possible.
>> Also, thinking about it, I'm not sure I see much of a use case for users
>> managing (for example deleting) individual databases.  (For many of the same
>> reasons as why we wouldn't let users delete individual ObjectStores.)  The
>> main problem is that there's a risk that apps will break if one database is
>> deleted and another isn't.  Some teams at Google have suggested that we
>> allow databases to be grouped such that one can't be deleted by the user
>> without deleting the others in the group.  Personally I think the easier way
>> to handle this is just not allow users to manage databases at a finer
>> grained level than per origin.
>> So, beyond these reasons, why else do we want the developer to supply a
>> description?  What are the use cases?
>>
>> If we decide to leave it in, I'm now leaning towards adding it to
>> setVersion.  There's no way to add any data (i.e. use any space) until you
>> call setVersion since that's necessary to create objectStores.  So even if
>> the UA wanted to display this while asking the user about doling out space
>> (despite my security concerns) or the UA wanted to display this in some
>> dialog for users to delete objectStores (despite my other concerns), it
>> would be possible.  If this happened, then essentially all meta-data would
>> be managed via setVersion, which seems nice.
>>
>> One other description related note: we probably need to establish a
>> maximum on name and description size and a maximum number of databases per
>> origin.  Otherwise one could (ab)use the name + description for key/value
>> storage of basically unlimited size.
>
> Conversation kind of died out on this.  Should we just remove description
> for now, or does anyone have any solid use cases (despite some of the
> problems I pointed out with description above)?

I don't really have strong opinions on the issue. While we can enforce
authors providing a description, which can be showed to users in
various UIs, we can't force them to provide a useful one. So the
description is effectively optional, it's just a question of how
strongly we encourage people to provide one.

Compare to the 'alt' attribute on <img> elements. It is encouraged
through the use of validators. A lot of people still don't provide
one, and yet more people provide one that isn't useful. But we still
keep encouraging people to provide an alt attribute, and IMHO rightly
so.

I think my vote goes towards keeping the description argument
required, otherwise it seems unlikely that people will ever provide
it. However I don't see much use of the IDBDatabase.description
property, so I vote for removing that. This way if implementations
want, they can completely ignore the argument. If implementations want
to display it somewhere in the UI, they can.

But I'd also be fine with other solutions. For example making the
argument optional.

/ Jonas

Received on Wednesday, 11 August 2010 19:46:32 UTC