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

I don't feel strongly.

I'll file a bug for our proposed solution.

On Thu, Aug 12, 2010 at 1:01 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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
>