W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

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

From: Andrei Popescu <andreip@google.com>
Date: Thu, 12 Aug 2010 00:48:01 +0100
Message-ID: <AANLkTinncTYNRjP-bxR2uyxfz3u_FEi00Pqx7BQgJY3q@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Jonas Sicking <jonas@sicking.cc>, Shawn Wilsher <sdwilsh@mozilla.com>, Webapps WG <public-webapps@w3.org>
On Thursday, August 12, 2010, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Wed, Aug 11, 2010 at 10:33 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>
> On Wed, Aug 11, 2010 at 1:30 PM, Andrei Popescu <andreip@google.com> wrote:
>> On Wed, Aug 11, 2010 at 8:45 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> On Wed, Aug 11, 2010 at 11:50 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
>>>> On Tue, Aug 10, 2010 at 12:26 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
>>>>>
>>>>> On Tue, Aug 10, 2010 at 11:30 AM, Andrei Popescu <andreip@google.com>
>>>>> wrote:
>>>>>>
>>>>>> On Mon, Aug 9, 2010 at 11:36 PM, Jeremy Orlow <jorlow@chromium.org>
>>>>>> wrote:
>>>>>> > On Mon, Aug 9, 2010 at 11:31 PM, Jonas Sicking <jonas@sicking.cc>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> On Mon, Aug 9, 2010 at 3:24 PM, Jeremy Orlow <jorlow@chromium.org>
>>>>>> >> wrote:
>>>>>> >> > On Mon, Aug 9, 2010 at 11:15 PM, Andrei Popescu <andreip@google.com>
>>>>>> >> > wrote:
>>>>>> >> >>
>>>>>> >> >> On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow <jorlow@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
> 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'm not totally sure I understand why you'd need all the heavyweight
setVersion() mechanism just to change the description. In the
setVersion() scenario, you're changing the schema but the description
is just some simple metadata. I think we're perhaps over-complicating
this?

Thanks,
Andrei


> J
>
Received on Wednesday, 11 August 2010 23:48:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT