This is great! Some thoughts on prioritisation and alternative APIs below...
On 9 February 2015 at 11:41, Paul Theriault <[email protected]> wrote: > 1. What APIs (or use cases) are the highest priority to expose to web > content? > Some criteria to consider might be: 1. The developer demand for the API (Number of apps in the Marketplace that use the API is one crude measure, we could come up with better measures) 2. The user value of the API (The kinds of experiences it unlocks for users, in which the web would otherwise be inferior to other app platforms, or in which the web could have a unique advantage. Not just on mobile, but across all form factors.) 3. The standardisation potential of the API (One implementation exposed to the web does not make a web standard, might other vendors be interested?) === Data Access === > Some APIs provide direct access to local data stores, e.g. contacts, > Device-Storage (pictures, video, music, sdcard). Access can be read-only or > full read/write access. 1. Developer demand for access to a shared storage area between apps seems very high, devicestorage is one of the top requested permissions, as is contacts. We don't know about DataStore because that's certified-only. 2. There's a lot of user value in apps which can access a central store of the user's data like contacts, photos and music. Does this need to be a local store? For offline operation it probably does. 3. What APIs could we standardise here? There's a new Filesystem API proposal [1] with potential interest from other vendors but it's still limited to a single origin, and you can already store binary blobs for a single origin in IndexedDB. Would we better to concentrate on something more like DataStore as a database shared between apps? Perhaps IndexedDB databases which can be shared between origins? Are there other more webby approaches we could take to some of these use cases, like replacing a shared offline file system with a shared online file store where each resource has a URL but is cached on the device, and accessed offline via some kind of cross-origin Service Worker? (I'm totally winging it here). ===Device Access=== > A number of FxOS APIs are created to provide access to various hardware > devices: e.g. Bluetooth, NFC, Motion Sensors, fmradio, wifi. > 1. These are not currently frequently used permissions, but that may simply because they're restricted to only certified apps. Some developers are certainly asking for them. 2. There are certainly use cases that can be unlocked by accessing these device features. Motion has some obvious applications on mobile. Control over Bluetooth, NFC, FMRadio and WiFi allows communication with other types of networks, but how much does this have to do with the web? 3. One thing to consider here is how long would web standards for these APIs be useful for? Technologies like Bluetooth/NFC/WiFi come and go and there are often competing standards. How would we feel today about the usefulness of a web standard to access a PS/2, SCSI or parallel port on a PC? Can we instead abstract away the use cases of these technologies and create more future proof APIs which are more technology agnostic? It sounds like this is being done to some extent with the Bluetooth proposal? === Unrestricted network access === > Some APIs provide local network access - e.g. SystemXHR, tcp-socket & > udp-socket. 1. Developers certainly want these things. SystemXHR is very popular (though we think that may be in part to a quirk of packaged apps). 2. There's definitely user value in apps which have unfiltered access to networks and it opens up a lot of new use cases but there's also a lot of risk. How feasible is it to create a UI to prompt the user on a per-network basis? (e.g. irccloud.com would like to communicate with irc.mozilla.org). Can we address some of the use cases without opening up full network access? An obvious example is the Network Discovery API + Presentation API as an alternative to tcp-socket access for casting media to a MatchStick type device. Could we build hosted versions of our email and calendar apps without these APIs? 3. Is there any interest in standardising these types of API from any other vendor? === Push Events & Notifications=== > Ability to receive push events, and display notifications to the user. We > already provide access to “push” permission. Why is wappush more > restricted? How do extend support to the web, not just web apps? (Im not > familiar enough with these APIs to answer this, maybe someone else can > comment). > 1. These are certainly commonly used features by developers. 2. There's clear user value and common applications across multiple form factors. 3. We already expose notifications and push to the web. There's already a standard for notifications [2] and a working draft for push [3]. What's still missing? wappush sounds like a legacy technology we shouldn't invest too much effort in? > === Audio Control === > Audio API (audio-channel-* & speaker-control) risks are mainly annoyance > and DoS of vital telephone services. These are likely solvable using a > combination of granting priority for privileged/certified applications, and > also figuring out a safe way for a user to switch audio priority to > foreground 3rd party apps. NB currently competing audio policy is only > allowed between loop and the dialer and requires both to co-operate. We > need a solution for hostile or poorly implemented apps. > 1. The audio channel API is fairly popular in the Marketplace. 2. More sophisticated use of audio by competing sources may not be a game changer, but could provide a better general user experience. 3. The AudioChannels API is not currently on a standards track according to MDN. This seems like something that has wide applicability across many platforms and form factors and could potentially be interesting to other vendors for standardisation though? > === SMS === > SMS is risky mainly due to the cost involved. Risks include cost of > sending SMS and also SMS are very sensitive - e.g. often used in 2-factor > auth (e.g. banking) > > === Telephony & Mobile === > Telephony & mobileconnection seem more dangerous - not sure that there is > a strong use case here? Thoughts? Do you really want websites making phone > calls, locking your SIM card? > 1. I'm not sure how many developers would like access to these functions? 2. There could be user value in providing alternative competing dialer and SMS apps, and other clever uses of these APIs (e.g. 2-factor auth), but are there more webby solutions to these problems? 3. Providing access to the legacy PSTN phone system via telephony & SMS APIs has been particularly challenging due to the certification and regulatory hurdles that come along with these systems. I question whether the effort required to try to expose these APIs to the web is worth it? We tried to standardised WebTelephony before and found a lack of interest from other vendors. Could we instead focus on creating cross-platform, cross-form-factor voice calling and messaging apps which don't directly access these functions of a device, but instead sync messages across devices and use WebRTC-based telephony when available? It may be that we need to support these legacy technologies on the smartphone form factor for a while using Firefox OS-only chrome privileged apps (it's going to be a long time until WebRTC can match the ubiquity and reliability of the phone system), but there's little value on other form factors. Other > Some other important ones that come to mind are alarms, camera and perhaps input. What more can we do here? 1. http://w3c.github.io/filesystem-api/Overview.html 2. https://notifications.spec.whatwg.org/ 3. https://w3c.github.io/push-api/
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
