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

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

From: Pablo Castro <Pablo.Castro@microsoft.com>
Date: Wed, 4 Aug 2010 17:32:49 +0000
To: Jeremy Orlow <jorlow@chromium.org>, Jonas Sicking <jonas@sicking.cc>
CC: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps WG <public-webapps@w3.org>
Message-ID: <F753B2C401114141B426DB383C8885E059007405@TK5EX14MBXC126.redmond.corp.microsoft.com>

From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Jeremy Orlow
Sent: Wednesday, August 04, 2010 2:56 AM

>> 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.
>>
>> J

+1

Nuking is fine...another option would be to queue up the delete until all database sessions are gone, but probably will complicate things and not add much. The only thing I wonder is if we'll create a bunch of pain for implementations where nuking is tricky (thinking of multi-process scenarios where maybe files are locked or something).

-pablo
 
Received on Wednesday, 4 August 2010 17:33:25 GMT

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