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