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. So, just to make sure we always have a description handy, it seems like maybe we should keep it non-optional. As for Jonas' comment about IDL: I believe the default is for null to turn into "null" and undefined to turn into "undefined", but IDL has ways of overriding the behavior. To me, "null" and "undefined" as database descriptions are pretty useless, but I don't see how we can spec that descriptions must be useful. Off the top of my head, it seems as though we could get away with making all strings in the IndexedDB treat null/undefined as an empty string, but would this be consistent with other specs in a predictable way? I'm not sure. But I think consistency/predictability for the user is the most important consideration. J On Mon, Aug 9, 2010 at 9:42 PM, Shawn Wilsher <sdwi...@mozilla.com> wrote: > On 8/9/2010 1:13 PM, Andrei Popescu wrote: > >> While implementing IDBFactory::open(), we thought that the >> "description" argument is optional but we were surprised to find out >> it's actually mandatory. Is there any reason not to make this argument >> optional? And, assuming it is optional, should the default value be >> the empty string? Also, how should the null and undefined values be >> treated? My suggestion would be to treat them as if the argument >> wasn't specified, so the description of the database would not change. >> > I think we want something there, because that is likely what the user agent > is going to tell the user when it has to ask for space (if the user agent > limits) or display if the user wants to see what a site is storing locally. > > I think we should probably enforce a non-null string too because of this, > although a null string for future connections meaning "do not change" seem > fine to me. I started a bug [1] a while back about what to do if it > changes, but it went nowhere. > > Cheers, > > Shawn > > [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9562 > >
