On 11/20/2015 02:42 PM, Justin D'Arcangelo wrote: > We are trying to grow our number of contributors. Anything that > lowers the barrier of entry and follows well-established patterns in > the community helps. Also, I’m not referring to jQuery, Angular, etc. > which all have *well-documented* syntax with easy-to-follow examples. > I’m talking about things like DeviceStorage, MozCamera, etc. There > was just a thread the other day where someone did not understand how > to enumerate a directory with DeviceStorage, so I’d say that this > *is* a problem.
But I wasn't talking about deviceStorage. Presumably, no matter the interface for our backend API, *we'd* be the ones dealing with deviceStorage's oddities. Someone using our Music backend certainly shouldn't have to care about deviceStorage. You also seem to imply that, had deviceStorage been implemented as an HTTP REST API, there wouldn't be confusion with it. However, I don't think that's true. If we're thinking of the same thread, the concerns with deviceStorage were about its semantics (e.g. the impossibility of listing the files in a directory NON-recursively), not its interface. Those issues would remain no matter how the API were accessed. > Using that logic, all our Gaia apps should currently have similar > design patterns and coding standards. Is anybody here going to > seriously argue that we already have that?! I'd argue that was a conscious decision on our part (and a bad one at that). When I started on Firefox OS, there was an active resistance to creating much in the way of shared code or creating/using a common API (especially for UI stuff). While we did have things like shared/js and the Building Blocks, the argument at the time was that we should each do the work from scratch, since using jQuery, etc wasn't "the web". However, nowadays we have a growing number of web components that we can just drop in to our apps. That alone will help to foster a degree of consistency among our apps. In fact, the NGA effort in general was about coming up with a set of ideas that all the apps should adopt. *Anything* we adopt universally will have a level of consistency. It doesn't necessarily need to be HTTP-based. > Versioning an API is something that happens all the time with HTTP > APIs. Usually all that’s needed is a bump in a version number to > change the URL pattern (e.g. /api/v2/…). Versioning an API doesn't necessarily make its semantics consistent across versions, nor does it make migration to a new version easy. I'd argue that richer syntax *does* make those things easier, since you can treat more things as implementation details. In this particular case, a JS-based API has the benefit of being able to pass non-string objects as arguments and extract the appropriate data internally. This frees the user of the API from worrying about what piece of the object is relevant to the API; they just pass the whole object and the implementation figures it out. >> In any case, if the performance issues with Service Workers remain, >> it may be better to provide a non-HTTP mode of communication if >> you're dealing with a database on the same device as your UI. > > If we are going to support other 3rd-party HTTP APIs in the back-end, > why on earth would we design a back-end that’s *not* HTTP? If you are > proposing that we have a thin JS wrapper that maps JS calls to HTTP > calls, then I’m all for it. But, it seems to me that if we wanted our > app to run on a UPnP back-end, we would effectively have to expose > our own UPnP services through an HTTP API, right? There are a few reasons we might choose not to access our backend via HTTP. First, if we open up the possibility of talking to another device that holds our media library, a logical extension of this is to talk to *multiple* servers[1]. These devices may also be far away from the user, and thus have a fair amount of latency when communicating. As a result, we may want to have local indexes of the user's "aggregate library" for performance. There's no benefit to these being accessible via HTTP, since they're local by definition. Second, as I mentioned above, we may choose to eliminate HTTP for our "local" library in order to improve performance. Even if Service Workers get faster than they are now, they still impose an additional layer of indirection (serialization/deserialization of all messages). They also force us to deal with the limitations of the platform's HTTP support, including the inability to send multiple messages as a response, and no "push" events. While there are proposals to add support for these things, I'd consider "using HTTP" to be premature at this point. Finally, we might find that the established HTTP APIs for our domain are missing features that we'd like to support in our app, at least for local libraries. As an off-the-cuff example, suppose we added the ability to edit metadata. If UPnP doesn't support that[2], it might prove easier to handle that without going through an HTTP API. For a single feature like this, it's probably easier to just add a proprietary extension to UPnP and still use that, but if we end up with many such features, it might be easier to just provide the front-end with direct JS-based access to the back-end. > This doesn’t make sense. If the back-end API is *not* HTTP, then what > is the transport? We should not assume that client and server will > always be on the same device if we want to scale up for the future. "Server" and "backend" aren't quite the same thing. Even apps which communicate with a server might have their own (local-only) backend. The email app is a good example of this: MIME parsing is part of the "backend", and yet it's something that you'd expect to run locally[3]. An HTTP API to parse MIME would just add complexity and a second parsing step (to parse the JSON returned from HTTP). Except for very-simple apps, I expect that there will be lots of cases like this: even when communicating with a Real Server, there's still a fair bit of "backend" processing that makes the most sense to be done locally. In these cases, an HTTP API provides little-to-no benefit. However, splitting up the front-end and the back-end still provides enormous benefit because it improves the readability, reliability, and testability of our code. - Jim [1] These servers might even use different protocols, e.g. UPnP/DLNA, Spotify, etc. In this case, a Javascript-based wrapper that unifies all the different protocols into a common API would be really helpful. [2] I don't think it does, but I haven't looked closely. [3] You want the result of the MIME parsing to be a bunch of objects (headers, bodies, etc) that you can pull from to render the message. _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
