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 <jo...@sicking.cc> wrote: > On Wed, Aug 11, 2010 at 4:05 PM, Jeremy Orlow <jor...@chromium.org> wrote: > > On Wed, Aug 11, 2010 at 10:33 PM, Jonas Sicking <jo...@sicking.cc> > wrote: > >> > >> On Wed, Aug 11, 2010 at 1:30 PM, Andrei Popescu <andr...@google.com> > >> wrote: > >> > On Wed, Aug 11, 2010 at 8:45 PM, Jonas Sicking <jo...@sicking.cc> > wrote: > >> >> On Wed, Aug 11, 2010 at 11:50 AM, Jeremy Orlow <jor...@chromium.org> > >> >> wrote: > >> >>> On Tue, Aug 10, 2010 at 12:26 PM, Jeremy Orlow <jor...@chromium.org > > > >> >>> wrote: > >> >>>> > >> >>>> On Tue, Aug 10, 2010 at 11:30 AM, Andrei Popescu < > andr...@google.com> > >> >>>> wrote: > >> >>>>> > >> >>>>> On Mon, Aug 9, 2010 at 11:36 PM, Jeremy Orlow < > jor...@chromium.org> > >> >>>>> wrote: > >> >>>>> > On Mon, Aug 9, 2010 at 11:31 PM, Jonas Sicking <jo...@sicking.cc > > > >> >>>>> > wrote: > >> >>>>> >> > >> >>>>> >> On Mon, Aug 9, 2010 at 3:24 PM, Jeremy Orlow > >> >>>>> >> <jor...@chromium.org> > >> >>>>> >> wrote: > >> >>>>> >> > On Mon, Aug 9, 2010 at 11:15 PM, Andrei Popescu > >> >>>>> >> > <andr...@google.com> > >> >>>>> >> > wrote: > >> >>>>> >> >> > >> >>>>> >> >> On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow > >> >>>>> >> >> <jor...@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 >
