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

Re: Cross-page locking mechanism for indexedDB/web storage/FileHandle ?

From: duanyao <duanyao@ustc.edu>
Date: Fri, 17 Jul 2015 10:13:20 +0800
Message-ID: <55A864C0.9080709@ustc.edu>
To: Joshua Bell <jsbell@google.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
I'm glad to hear that somebody has been working on this issue!

After read your proposal and previous dicussion, I realized that such 
locking mechanism doesn't have to be tied to specific storage mechanism, 
and a promise-based API
is more general than a synchronous API.

在 2015年07月16日 01:12, Joshua Bell 写道:
> Based on similar feedback, I've been noodling on this too. Here are my 
> current thoughts:
> https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191
> Feedback welcome - I was planning to send this around shortly anyway.
> On Wed, Jul 15, 2015 at 3:07 AM, 段垚 <duanyao@ustc.edu 
> <mailto:duanyao@ustc.edu>> wrote:
>     Hi all,
>     I'm developing an web-based editor which can edit HTML documents
>     locally (stored in indexedDB).
>     An issue I encountered is that there is no reliable way to ensure
>     that at most one editor instance (an instance is a web page) can
>     open a document at the same time.
>     * An editor instance may create a flag entry in indexedDB or
>     localStorage for each opened document to indicate "this document
>     is locked", and remove this flag when the document is closed.
>     However, if the editor is closed forcibly, this flag won't be
>     removed, and the document can't be opened any more!
>     * An editor instance may use storage event of localStorage to ask
>     "is this document has been opened by any other editor instance".
>     If there is no response for a while, it can open the document.
>     However, storage event is async so we are not sure about how long
>     the editor has to wait before opening the document.
>     * IndexedDB and FileHandle do have locks, but such locks can only
>     live for a short time, so can't lock an object during the entire
>     lifetime of an editor instance.
>     In a native editor application, it may use file locking
>     (https://en.wikipedia.org/wiki/File_locking) to achieve this purpose.
>     So maybe it is valuable to add similar locking mechanism to
>     indexedDB/web storage/FileHandle?
>     I propose a locking API of web storage:
>       try {
>         localStorage.lock('file1.html');
>         myEditor.open('file1.html'); // open and edit the document
>       } catch (e) {
>         alert('file1.html is already opened by another editor');
>       }
>     Storage.lock() lock an entry if it has not been locked, and throw
>     if it has been locked by another page.
>     The locked entry is unlocked automatically after the page holding
>     the lock is unloaded. It can also be unlocked by calling
>     Storage.unlock().
>     What do you think?
>     Regards,
>     Duan Yao
Received on Friday, 17 July 2015 02:14:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:57 UTC