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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349

One quesiton though: if they pass in null or undefined, do we want to
interpret this as the argument not being passed in or simply let them
convert to "undefined" and "null" (which is the default behavior in WebIDL,
I believe).  I feel somewhat strongly we should do the former.  Especially
since the latter would make it impossible to add additional parameters to
.open() in the future.

J

On Thu, Aug 12, 2010 at 11:37 AM, Jeremy Orlow <jorlow@chromium.org> wrote:

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