> You can't trade one use case with another. I was referring to startup races and initialization, not callbacks. Promises can easily guard this, and we do so all over gaia in other classes.
> Share libraries can serve us right in a few things but wrapping mozSettings API shouldn't be one of it. I think one of the nice things of having a helper is the ability to have a nice method (like SettingsObserver.observe), which listens to changes as well as calls the callback with the current setting. I'm in favor of doing a lightweight API wrappers where it makes our code a lot less verbose. One option here is to add this to the platform, but we've often gotten pushback in the past when adding things like this to the platform, and thus, a library is born. I don't think that this is necessarily bad, and it follows the extensible web manifesto, https://extensiblewebmanifesto.org/ Best, Kevin On Sun, Jul 26, 2015 at 11:07 PM, Tim Guan-tin Chien <timdr...@mozilla.com> wrote: > On Sun, Jul 26, 2015 at 4:18 AM, Kevin Grandon <kgran...@mozilla.com> > wrote: > >> 2) Races, start-up races everywhere > > > > This seems easy to fix by having the observer return a promise, and > wrapping > > it with .then(). > > > > I disagree. The callback on the original observer was intended to be > invoked multiple times, while the Promise interface is the paradigm > for one-and-done action. You can't trade one use case with another. > > That does not automatically defuse the start-up races either if the > caller don't use to the returned promise at all, and we can't detect > that from the library. > > >> 3) It hides lock management from the caller > > > > I personally feel that getting rid of the library is going to create more > > races. I think the helper library is a nice abstraction, and if done > > correctly can help us reduce race conditions. > > > > > >> I personally did a implementation in Keyboard app too [1], but it might > >> not be general enough. > > > > What were the reasons to re-invent the settings wrapper instead of > making it > > better? > > > > > > Can you post an example of a settings observer with and without the > library? > > Currently my preference is to keep the existing library and make it > better. > > I do not think that we should keep inventing additional wrappers in each > > app, and should instead take some time and make the version in shared/ > > better. > > > > Best, > > Kevin > > > > To add an observer, simply |navigator.mozSettings.addObserver(key, > callback);|. > > One of the best things on working in Gaia is that we control Gecko and > these proprietary APIs too. In the specific instance of mozSettings > API, I feel that the use of shared library have prevent us to take the > feedback back the platform. Share libraries can serve us right in a > few things but wrapping mozSettings API shouldn't be one of it. > > I also don't think it would be a lot extra burden for apps to create > their own code interaction with the API. Each of our apps are being > design and developed in different pace and different use cases -- > pushing that responsibility to apps ask app developers take full > control to interact with the API responsibly. >
_______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
