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

Re: [IndexedDB] Need a method to remove a database

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 4 Aug 2010 11:15:54 -0700
Message-ID: <AANLkTikfEbdkpS9XSozYZ2L_YnJFASU6BMp2GenWxXMu@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps WG <public-webapps@w3.org>
On Wed, Aug 4, 2010 at 2:56 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Tue, Aug 3, 2010 at 11:26 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Tue, Aug 3, 2010 at 3:20 PM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:
>> > Hey all,
>> >
>> > Some of the feedback I've been seeing on the web is that there is no way
>> > to
>> > remove a database.  Examples seem to be "web page wants to allow the
>> > user to
>> > remove the data they stored".  A site can almost accomplish this now by
>> > removing all object stores, but we still end up storing some meta data
>> > (version number).  Does this seem like a legit request to everyone?
>> Sounds legit to me. Feel somewhat embarrassed that I've missed this so far
>> :)
> Agreed.
> What should the semantics be for open database connections?  We could do
> something like setVersion, but I'd just as soon nuke any existing connection
> (i.e. make all future operations fail).  This seems reasonable since the
> reasons we didn't do this for setVersion (data loss) don't really seem to
> apply here.

Actually, there could dataloss apply here. Consider a page which
creates a temporary database, fills it with data, and then slowly
sends it to the server. Once all data has been sent to the server the
database is removed.

If you have two instances of that page open, one could remove the
database while the other is still writing to it.

Though this seems like a pretty scary setup anyway since if the user
closes the second page midway through, the first one will succeed in
deleting the database no matter what.

/ Jonas
Received on Wednesday, 4 August 2010 18:16:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC