On Monday, February 9, 2015 at 9:41:33 PM UTC+10, Paul Theriault wrote: > Following up on the previous discussions [1] [2] I've been doing some > analysis of the current app permission model for FxOS. This email is to start > discussion around exposing APIs to web content - i.e. hosted apps and regular > websites. I made some notes [3] and a table of all permissions [4] and below > is a summary of observations to get the discussion started. Note the premise > of this exercise was to explore what is possible to expose to websites. Im > still currently of the opinion that an app signing mechanism is going to be > needed, and we should improve our packaging model to be more web friendly, > but I wanted to explore how far we can get without app packaging/signing. > This email is long, but it basically comes down to 2 questions: >
Thanks for putting these together. I would highly recommend that for any feature people want to add to the Web, people follow the DOM team's guidelines for adding new things to the Web Platform: https://wiki.mozilla.org/WebAPI/DesignGuidelines It's fine if we want to keep adding things to the FxOS Platform (as long as we understand that *that is not the Web Platform*), but if we want to add things to the Web Platform, then the above should help us get there. As always, people on the DOM team that work on standards are always happy to help in standardizing stuff (given use cases and shown the value a new feature would bring to the Platform) - it's what we are here for, and we can help foster ideas, tease out use cases, design APIs, or even to say "you know, the Web already does X and Y, so that solves your problem without needing to add anything new!" <- the best option; Looking at you, SystemXHR! :) Standardization is a long process and what comes out the other end rarely looks like whatever when in. So, it's extremely rare that we will be able to take feature X and just standardize it: we can instead take the use cases of feature X, and a proposal that works, and work with other stake holders of the platform to get agreement on some specification (which ultimately becomes a standard). More often than not, standardization will fail for a number of reasons (discussed in the link above). A general note: by design, the Web Platform is not architectured the same way as a native platform. It has a clear defined security model that is not compatible (again, by design) with traditional software models - which is why trying to impose a packaged apps model on it doesn't work well; and why trying to bolt on "system APIs" on it doesn't work. This is mainly why things like telephony/dialer, SMS, low-level bluetooth, raw sockets, audio control etc. don't make sense on the Web (they are system level things outside the scope of a web page - and hence could be written in, say, c++ or Rust or Swift... which is why the Web works well with, say, MacOS, iOS, Windows 8, or your favorite Linux flavor). It's always best to work within the constraints of the Web platform then to radically change it. As you mentioned, the right approach is to do what the W3C Web BlueTooth CG is trying to do: work from the use cases that make sense for the Web (e.g., it doesn't make sense to configure bluetooth audio devices in a web page - you do that at the OS level; just like it doesn't make sense to have multiple telephony dialers: a web page can ask to make a call through a dialer, but not be a dialer... and so on). Hope that helps! _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
