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. Thanks, Andrei
