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

On Wed, Aug 11, 2010 at 4:05 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Wed, Aug 11, 2010 at 10:33 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Wed, Aug 11, 2010 at 1:30 PM, Andrei Popescu <andreip@google.com>
>> wrote:
>> > On Wed, Aug 11, 2010 at 8:45 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> >> 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.
>> >>
>> >
>> > I guess I am still not convinced that showing 'description' in the
>> > browser UI is a good idea, but that's up to each implementation to
>> > decide. My vote would be to remove IDBDatabase.description and make
>> > the argument optional.
>>
>> I think the UI where I'd think we'd want to show it is in the UI that
>> allows users to inspect and delete individual databases. We don't have
>> this UI yet, so I'm not sure what it'll look like though.
>>
>> Seems to me like removing IDBDatabase.description and making the
>> argument optional is a decent compromise between the various opinions
>> here?
>
> I'm fine with that, but what about also grouping it in with setVersion.  To
> me, this makes sense because then all database related meta-data/schema
> stuff will be set in one place.  And since you can't store any data without
> adding objectStores, there's no way a UA would need the
> description information until after the first setVersion call.  If we do
> this, we could even leave database.description (even though I agree it's not
> super useful).  If we did this, it'd be a non-optional parameter of
> setVersion, but of course someone could supply "" as the argument.
> Thoughts?

I feel like description is something that belongs on the database. It
generally shouldn't be associated with a particular version of the
database. So I would prefer to keep it where it is now.

/ Jonas

Received on Thursday, 12 August 2010 00:02:07 UTC