Hi,
My comments refer to the wiki page as it currently is [1].
This API resembles a lot of the Storage API [2] or the ES6 Maps (already
implemented in SpiderMonkey). It might be worth subclassing these than
creating once again a new key->value API, no?
Regarding the lock system, I'm not sure I fully understand what it is.
It looks to me that it's more a transaction mechanism than a lock. That
is, every operation performed by the "lock" has to be performed before
any operation of another "lock" can be performed.
Does instantiating a lock prevent instanciating another lock in the same
or another context? If no, then, I don't think it's a "lock".
Also, in the following case:
var lock1 = SettingsManager.getLock();
var lock2 = SettingsManager.getLock();
lock1.set({a: 1})
lock1.set({b: 2})
lock2.set({c:3})
setTimeout(function(){
lock1.set({d:1});
}, 0)
Are operations of lock2 happening at all or does it have to wait for
lock1 to be GC'ed or something like that? I feel no, but it's not
obvious, especially with the "lock" terminology.
In the SettingsEvent, it isn't clear whether the settingValue is the
previous or the new one. StorageEvent solved this issue by providing both.
"SettingsRequest will be similar to SMSRequest described in WebSMS
specification. "
=> Yes. This is a promise too :-)
David
[1]
https://wiki.mozilla.org/WebAPI/SettingsAPI
[2]
http://www.w3.org/TR/webstorage/#the-storage-interface