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

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.

J