- From: Aaron Boodman <aa@google.com>
- Date: Wed, 9 Sep 2009 11:30:43 -0700
On Wed, Sep 9, 2009 at 11:23 AM, Darin Fisher<darin at chromium.org> wrote:
> On Wed, Sep 9, 2009 at 11:08 AM, Aaron Boodman <aa at google.com> wrote:
>> There would presumably have to be a separate name value for each API,
>> though, right? So we're talking about the difference between:
>>
>> window.acquireLock("localStorage", function() {
>> ...
>> });
>>
>> and:
>>
>> window.acquireLocalStorage(function() {
>> ...
>> });
>>
>> It doesn't seem like much of a win for reusability IMO.
>
> I wanted to leave it up to the app developer to choose the name so that they
> could define how the lock is interpreted.
> For example, they might want to partition the keyspace for local storage and
> have separate locks for separate keys. ?Or, they might want to have a single
> lock that is inclusive of several storage mechanisms: LocalStorage and
> FileAPI.
> Besides, once we have an explicit locking API, why not just be generic and
> give it a name divorced from LocalStorage or any kind of storage features
> for that matter? ?Locking can be useful to other applications that do not
> even use local storage...
I see.
So you are suggesting the localStorage could have zero concurrency
guarantees and it is simply up to the developer to arrange things
themselves using this new primitive.
That is an interesting idea. You're right that it overlaps with the
ideas that inspired shared workers, and the global script proposal.
- a
Received on Wednesday, 9 September 2009 11:30:43 UTC