Basically +1 to everything Jim has been saying here. When service workers are ready, I think that some of our apps will be able to make good use of them. For those apps, designing an HTTP API may make a lot of sense. The Music app involves a lot of database queries, which map nicely to REST APIs, so encoding method calls as URLs was a fairly natural fit there (even though it the app is not actually using sevice workers or HTTP).
Other apps may not have much use for service workers and will have their backends in a regular web worker or iframe. For those apps, a JSON-based postMessage/threads.js API will be a more straightforward and flexible choice. I think that Gallery will probably be one of these apps. And some apps (like Camera) are pretty much all front-end and may never adopt the NGA architecture at all. This is an app that will never be "webby", and that is okay. But I really would like to shift our focus away from our core set of Gaia apps and onto the OS itself. What can we do in the 2.6 release cycle to improve the portabilty and performance of the FirefoxOS platform? What can we do to make it a great OS to develop apps on? David On Fri, Nov 20, 2015 at 1:40 PM, Jim Porter <[email protected]> wrote: > On 11/20/2015 02:17 PM, Benjamin Francis wrote: > > On 20 November 2015 at 19:36, Jim Porter <[email protected] > > <mailto:[email protected]>> wrote: > > > > While using HTTP internally might allow for some new features (like > > running the backend on a different system), > > > > > > Exactly, what if the back end could run on a server as a web service, > > with a Service Worker as a progressive enhancement to make it work > > offline? > > This makes the false assumption that we'd benefit from splitting the > front-end and the back-end up onto different devices. That's not always > the case. > > For some apps (e.g. dialer or camera), the point is that you're > communicating with hardware on the device you're holding in your hand > (you could have a "remote camera", but I expect the UI would be a lot > different). > > For other apps (e.g. email), they already communicate with a remote > server, and I don't know if there's much benefit to moving its backend > code (MIME parser, local database) to another device. > > For still other apps (e.g. music, video), it makes sense to have a > backend on a different device, but in many cases, such backend protocols > are already defined, and aren't just HTTP (UPnP/DLNA uses RTSP for media > data, for example). Even then, you'd likely want some parts of the > backend to always be on your device, e.g. a local version of (parts of?) > the database so that queries can be faster. > > > What if the app could work in multiple browsers? > > A pure Javascript API would also work in multiple browsers without > issue. In fact, it would probably work *better* than an HTTP API, since > you'd be less likely to need brand-new browser features to make it work. > > > What if that API was also accessible by other apps so that we didn't > have to use > > proprietary cross-app messaging APIs? What if that cross-app messaging > > could also work locally using cross-origin Service Workers? What if we > > could replace other local proprietary JavaScript APIs in Gecko with web > > services? > > Why do those APIs have to be proprietary? If we come up with a really > good API that's not HTTP-based, I'm sure we could push to standardize > it. I'm all for purging the Inter-App Communications API, but in the > Music app at least, the alternative isn't Service Workers; I believe > there's an API in the works to allow media keys (e.g. on physical > keyboards, in the lockscreen, etc) to control playback. As far as I > know, it's on the standards track, although I can't recall the name > off-hand. > > > I don't think a REST API as a back end is inherently easier or more > > performant, but it is good practice, it is the web, and it does make our > > code much more portable. Currently Gaia is not of the web. > > If it's not inherently easier or more performant, why is it good > practice? Is it good practice simply because it's "the web"? I disagree > that it makes our code more portable, since plain-old Javascript is at > least as portable. It might be more portable in certain specific > scenarios (e.g. if you need inter-app communications and don't have a > better standardized way of handling it), but not every app needs that, > nor does it mean the *entire* backend needs to be exposed via HTTP. > > > Even > > if we used HTTP internally, we might find it preferable to expose an > API > > that takes advantage of all the syntactical niceties of modern > > Javascript. ... > > > > We could do that too. > > At that point, HTTP is just an implementation detail, and we could defer > using HTTP in a given app until we decide it's actually better than just > running the Javascript "directly". For some apps, that might come along > pretty soon; for others, it might never happen. > > - Jim > _______________________________________________ > 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
