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

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?

J