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
