Results of the questionnaire on proposed SysApps deliverables

Summary from Questionnaire Deliverables for the SysApps charter.

Notes

Application API

Jonas Sicking: The scope of the Application API is pretty fluffy. WebIntents seems to perfectly fit the current description for example.

Messaging API

Jonas Sicking: We're not interested in a generic "Messaging API" at this time. We are interested in specific SMS/MMS APIs though. Possibly also E-mail/IM.

Eduardo Fullea: Messaging, Telephony and Contacts form the set of key communication APIs to be dealt with in Phase 1

Power Management API

Jonas Sicking: I think the Power Management API is a very low priority API since it's only really useful for a "window manager" or "desktop" application. Not useful for installed "apps".

Telephony API

Jonas Sicking: We might be able to help edit the Telephony API, but I'm not sure.

Eduardo Fullea: Messaging, Telephony and Contacts form the set of key communication APIs to be dealt with in Phase 1

Background Services API

Adam Barth: We expect that we'll want to address these use cases (Background Services) as part of the runtime model.

Jonas Sicking: We might be able to help edit the Background Services API, but I'm not sure.

Bluetooth API

Jonas Sicking: We would be interested in the Bluetooth API, but it's not a high priority for us given the complex security concerns and the relatively speaking few apps that need this API. We might be able to help edit, but I'm not sure.

Calendar API

Adam Bath: We're interested in the Calendar API, but the folks at Google who are able to review this specification aren't available to help at the moment.

Jonas Sicking: We might be able to help edit the Calendar API, but I'm not sure.

Adam Barth: It's possible that we'd be willing to help edit the Contacts API, but it's not a high priority for us.

Contacts API

Jonas Sicking: We might be able to help edit the Contacts API, but I'm not sure.

Eduardo Fullea: [wrt Contacts API] Messaging, Telephony and Contacts form the set of key communication APIs to be dealt with in Phase 1

Device Capabilities API

Jonas Sicking: We have been hoping that feature detection as well as capability-features of individual APIs can fill the need for the Device Capabilities API. For example the camera API should make it possible to detect which cameras the device has.

DNS Resolution API

Adam Barth: The DNS Resolution API isn't a high priority for us, but we have resources lined up for when this spec reaches the top of the agenda.

File System API

Adam Barth: The File System API is important, but we believe it will be contentious. It's not clear now this spec differs from the Media Storage API.

Jonas Sicking: Hopefully we can help with editing the File System API, but I'm not sure yet.

Keyboard/IME API

Wayne Carr: Is the Keyboard/IME API needed in addition to Web Apps API?

Network Interface API

Jonas Sicking: The Network Interface API is a low priority to us.

Media Storage API

Adam Barth: It's not clear to us how the Media Storage API is different from the File System API listed above. That might be related to different groups having different visions for how to address these use cases.

Jonas Sicking: Hopefully we can help with editing the Media Storage API, but I'm not sure yet. How is this different from the File System API?

Brian LeRoux: kinda skeptical of the Media Storage API given we have idb and file apis.

Wayne Carr: Other comments are about difference of the Media Storage API from the file api. this is more about media metadata for video, music, etc. and efficient search for media location based on that.

Resource Lock API

Jonas Sicking: Hopefully we can help with editing the Resource Lock API, but I'm not sure yet.

Secure Elements API

Brian LeRoux: The Secure Elements API is generally impossible on mobile (no secure keystore on any platform yet really) but we can fake it w/ a server/auth hop

Sensor API

Wayne Carr: Long history in DAP where fingerprinting is more of an issue (because standalone apps don't typically wander from site to site like a Web Browser). If DAP doesn't create a general Web Intents based approach, sysapps should (for sensors on the device and local network).

Serial API

Adam Barth: The Serial API should be almost trivial once the working group agrees on the Raw Sockets API.

Jonas Sicking: [wrt Serial API] Also a floppy disk API? ;-)

USB API

Jonas Sicking: We would be interested in the USB API, but it's not a high priority for us given the complex security concerns and the relatively speaking few apps that need this API. We might be able to help edit, but I'm not sure.

Web Intent Registration

Adam Barth: We think this use case (Web Intent Registration) should be addressed in the manifest, which isn't yet on the agenda.

Additional Deliverables

Brian LeRoux: I might even go so far as to say LESS deliverables in the first phase would be more pragmatic!

Suresh Chitturi: Unfortunately, we are not in a position to formally commit to any specific APIs at this point. However, in general, we would like to see a far fewer deliverables and no mention of Phase 1 and Phase 2. It is more important to define the execution and security model and a few APIs to demonstrate the framework, as opposed to overloading the charter with a laundry list of APIs. There are specific APIs that can be easily removed such as Secure Elements API (moving it to NFC WG), Serial API (no references to existing work, evidence of strong use cases), etc.

Wayne Carr: If there is progress on a draft and WG members want to work on it, we should let it happen, not say the charter forbids it. Suggesting what is in phases is fine, not mandating it. The WG will, as usual, be able to decide what it advances to various stages.