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

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

J