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

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 <sdwilsh@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
>
>