On 11/20/2015 04:05 PM, David Flanagan wrote: > 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).
As I mentioned in another message, even for Music, it's debatable if an HTTP API is the best long-term strategy. Eventually, I think we'd like to support streaming from libraries on other machines (via UPnP/DNLA, Ampache, Spotify, AURA, etc). All of these have different HTTP APIs[1], despite doing similar things. It would make sense to wrap all these APIs in a compatibility layer so that, to the rest of the app, they look the same (maybe with some capabilities flags for each to enable/disable features). This compatibility layer could be an HTTP API, but it seems rather excessive to wrap one HTTP API with another. I can't imagine it'd be good for performance either, since we'd have to box/unbox data twice as much. Instead, I think the compatibility layer should have a Javascript API. This is more efficient, and also lets us add all the convenience functions that we might want but can't easily provide via HTTP (I think most people already agree that a Javascript-based "convenience API" is an ok-to-good idea). Once such an API exists, it becomes logical to implement our local backend in terms of that API. Thus, the local backend is accessed via a Javascript API. Now, we could still provide access to our local Music backend over HTTP (say, via UPnP) so that people could run a headless Music app on their desktop to manage their library, but I'm not sure why we'd bother. There are already dozens of UPnP media servers out there, and I don't think we gain much by throwing our hat into the ring. Why not just let other folks worry about making the remote server so we can focus on making the best client we can? - Jim [1] Well, mostly HTTP. UPnP uses RTSP for transferring the actual media. I don't know a whole lot about Ampache either, but I think it uses HTTP. _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
