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
_______________________________________________
dev-fxos mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-fxos
