> On Nov 20, 2015, at 10:38 PM, [email protected] wrote: > > On Friday, November 20, 2015 at 5:53:35 PM UTC-8, Andrew Sutherland wrote: >> On 11/20/2015 03:17 AM, Zibi Braniecki wrote: >>> I'm a bit afraid of getting this mingled with real back-end and ending up >>> with back-end that resolves localization strings because they need them for >>> notifications but then, slowly expands to store localized strings for its >>> front-end as well, so I'd love to see this back-end "front-end" code that >>> sends notifications and alarms somehow isolated, but unless there's other >>> reason to do that, we'll have to just be mindful. :) >> >> A thing we've been doing in the email app conversations branch (which >> uses require.js-style AMD modules) is to have the back-end require() >> modules provided by the front-end. For example, the back-end does >> require('app_logic/conv_churn') to get the front-end-provided helper >> method that decides what (extra) information goes in the conversation >> summary object. >> >> And this is what I plan to do for the periodic sync implementation on >> the conversations branch. The front-end gets to decide what it wants >> the notifications to look like, so it provides the logic and the strings >> and formats them. >> >> But this is where we get into a terminology problem. What would be >> desired is for that front-end provided logic to be running in the >> back-end's Worker/SharedWorker/ServiceWorker. So it is front-end logic, >> but in a back-end context, in a way. And it looks like all the code in >> https://github.com/mozilla-b2g/gaia/blob/master/shared/js/intl/ is >> assuming that it's operating in a Window, not a *Worker. (Or maybe >> that's misleading and a side-effect of an overzealous transpiler/bundler?) >> >> So I guess my question is: Is it currently possible or eventually >> planned to allow the l20n.js code to run in a worker context? >> >> Andrew >> >> PS: Relatedly, after looking at that directory: It is possible to put a >> README.md in gaia/shared/js/intl that explains that the code is >> transpiled from https://github.com/l20n/l20n.js or wherever it comes >> from? That's likely to save intrepid explorers a lot of headaches! > > Thinking about the API discussions on this thread, I have come to a place > similar to what Andrew has just communicated. My thought is that it's too > early in the "NGA conversion process" to choose a specific API mechanism for > making the front-end/back-end separation. I believe it would be extremely > useful to have practical experience with both the implementations being > discussed (it seems most of the conversations are regarding HTTP vs. > javascript) to better understand their value to us. We already have the > benefit of the music app using an HTTP API; it seems likely that in the 2.6 > timeframe there could be a gallery app with a javascript-based API supporting > its front/back-end separation. Having actual implementations using a couple > of known, popular API mechanisms will help us make informed decisions as we > continue to evolve the platform and apps. > > -Russ
To be extra clear here about the back-end API in the Music app, the HTTP API we expose is nothing more than a thin wrapper around a bridge.js “JavaScript” API. But, we chose to impose certain limitations on our “JavaScript” API so that every method was handled via an async call and response in order to make it possible for such a thin HTTP wrapper to exist easily. Therefore, these HTTP API methods: https://github.com/mozilla-b2g/gaia/blob/master/apps/music/js/view.js#L10-L54 <https://github.com/mozilla-b2g/gaia/blob/master/apps/music/js/view.js#L10-L54> map up to these bridge.js API methods: https://github.com/mozilla-b2g/gaia/blob/master/apps/music/js/endpoint.js#L17-L67 <https://github.com/mozilla-b2g/gaia/blob/master/apps/music/js/endpoint.js#L17-L67> We should already have a pretty clear understanding of what the pros and cons of both approaches are. For example, with traditional HTTP APIs, you expect to send a request to the back-end and get an async response in a single shot. However, this means that certain types of API calls involving enumeration must be thought about differently. One such example is the way the Music app used to enumerate MediaDB was to pass a callback function to the query which would get called iteratively for each record in the results. This implies a stream-like behavior that is not currently supported over HTTP through ServiceWorkers AFAIK. One valid reason I’ve heard from Jim in favor of this type of iterator callback API is that it would allow the first few records of data in a given query to be put on-screen faster. That being said, there are several ways to solve the “get data on-screen fast” problem with an HTTP API, one of which is to have paginated calls so you can get the first 10-20 records super-fast and defer the query for the remaining items. Another solution is “better caching” which can be solved any number of various ways via ServiceWorkers or other means. > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
