On Fri, Sep 26, 2014 at 2:35 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
> On 2014-09-26, 5:20 PM, Jonas Sicking wrote:
>>>
>>> Also currently mozSettings.createLock().get()/set() doesn't smell nice. A
>>> promise is something developer wants.
>>> It'd be nice if we have read/write without creating a lock and maintain
>>> on
>>> our own.[4]
>>> ```js
>>> mozSettings.read('lockscreen.enabled').then(function(value) {});
>>> ```
>>
>>
>> This I completely agree with. The createLock() function provides
>> transactional protection, but I suspect that's not something we really
>> need for settings. That was my bad idea.
>
> Do you mean we can just remove the locking concepts from this API?To the extent that backwards compatibility allows it yes. Maybe the simpler solution is to add .get()/.set() (or .read()/.write() if there's a strong preference for that) directly on mozSettings and make those functions non-transactional. Then people can migrate code as they see fit to using that. Eventually we can look at the code to see if any of the remaining users of createLock() actually needs transactions, and remove createLock() if they don't. >> And yes, we should definitely switch from using DOMRequest to using >> Promises. I think we can actually do this as a two-step process. >> >> 1. Add a .then() function to DOMRequest. This will magically make all >> DOMRequests also work as promises. While still maintaining backwards >> compatibility so that we don't have to rewrite all existing code at >> once. > > Just assigned bug 839838 to myself. :-) Awesome! / Jonas _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
