On Fri, Nov 20, 2015 at 3:03 PM, Justin D'Arcangelo <[email protected] > wrote:
> Just an FYI, we have already started planning the work to move Camera over > to NGA. > > While much of the NGA plan includes parts of the platform that are not > quite 100% ready to go yet (e.g. ServiceWorkers), we should not exclude > them from our designs. We are building for the future. Of all the apps that > would benefit tremendously from an HTTP-based back-end, I would think > Gallery would be at the very top of that list. > The gallery back end does metadata parsing and image processing. I don't see how HTTP helps here at all. (In fact, we lose the ability to treat ArrayBuffers as Transferrable objects if we switch from postMessage() to an HTTP API where data has to be copied.) If you're talking about defining an HTTP API to device storage so that Gallery can inter-operate with remote file storage services, that's actually an interesting idea, but is out of scope for now. > If the app owners cannot agree to follow the architecture that the NGA > group has spent many months defining and validating, > HTTP APIs for communication between front-end and back-end code is not actually part of the NGA proposal, so you can't accuse me of not following the architecture :-P. And, we've only validated the frontend/backend split part of NGA. All the interesting and hard stuff involving service workers, caching, app updates and page transitions has not been validated yet. > then I really don’t know how we’ll ever scale FxOS up to meet our future > needs. > If you feel that you understand what our future needs are, I'd be very interested to have you write up your vision and explain how NGA and HTTP APIs help us meet those future needs and explain what you mean by "scale up". (Not being snarky here. I really want to understand where you're coming from on this.) David > > -Justin > > > On Nov 20, 2015, at 5:05 PM, David Flanagan <[email protected]> wrote: > > 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 > > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
