w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire Deliverables for the SysApps charter
The results of this questionnaire are available to anybody.
This questionnaire was open from 2012-06-05 to 2012-06-13.
10 answers have been received.
Jump to results for question:
- Your organization
- Alarm API
- Application API
- Messaging API
- Power Management API
- Raw Sockets API
- Telephony API
- Accounts API
- Background Services API
- Bluetooth API
- Browser API
- Calendar API
- Contacts API
- Device Capabilities API
- DNS Resolution API
- File System API
- Idle API
- Keyboard/IME API
- Network Interface API
- Media Storage API
- Resource Lock API
- Secure Elements API
- Sensors API
- Serial API
- Spellcheck API
- System Settings API
- USB API
- Web Intent Registration API
- Additional deliverables
1. Your organization
Please enter the name of your organization.
Details
| Responder | Your organization |
|---|---|
| Adam Barth | |
| Jonas Sicking | |
| Jérôme Giraud | |
| Sylvain Lalande | |
| Brian LeRoux | |
| Virginie GALINDO | |
| Jungkee Song | |
| Suresh Chitturi | |
| Wayne Carr | Intel Corporation |
| Eduardo Fullea |
2. Alarm API
summary | by responder | by choice
An API to manage the system's alarm daemon.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 3 |
| My organization is interested in helping to edit the specification for this API | 3 |
| My organization expects to provide an implementation report for this API | 5 |
| My organization expects to provide test cases for this API | 3 |
| My organization is interested in providing use cases for this API | 3 |
Skip to view by choice.
View by responder
Details
| Responder | Alarm API | Comments |
|---|---|---|
| Adam Barth |
|
|
| Jonas Sicking |
|
|
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song |
|
Tizen Alarm API: https://developer.tizen.org/help/topic/org.tizen.help.web.api.device/tizen/alarm.html |
| Suresh Chitturi | ||
| Wayne Carr |
|
(Tizen impl, api) |
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
3. Application API
summary | by responder | by choice
An API to launch other applications and communicate with them.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 1 |
| My organization is interested in helping to edit the specification for this API | 1 |
| My organization expects to provide an implementation report for this API | 2 |
| My organization expects to provide test cases for this API | 2 |
| My organization is interested in providing use cases for this API | 2 |
Skip to view by choice.
View by responder
Details
| Responder | Application API | Comments |
|---|---|---|
| Adam Barth | ||
| Jonas Sicking | The scope of this API is pretty fluffy. WebIntents seems to perfectly fit the current description for example. | |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO |
|
|
| Jungkee Song |
|
Tizen Application API: https://developer.tizen.org/help/topic/org.tizen.help.web.api.device/tizen/application.html |
| Suresh Chitturi | ||
| Wayne Carr | ||
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
4. Messaging API
summary | by responder | by choice
An API to send and receive messages (e.g. SMS, MMS, Email, IM) as well as manage messages stored on the device.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 3 |
| My organization is interested in helping to edit the specification for this API | 3 |
| My organization expects to provide an implementation report for this API | 3 |
| My organization expects to provide test cases for this API | 3 |
| My organization is interested in providing use cases for this API | 4 |
Skip to view by choice.
View by responder
Details
| Responder | Messaging API | Comments |
|---|---|---|
| Adam Barth | ||
| 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. | |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO |
|
|
| Jungkee Song |
|
Tizen Messaging API: https://developer.tizen.org/help/topic/org.tizen.help.web.api.device/tizen/messaging.html |
| Suresh Chitturi | ||
| Wayne Carr |
|
(Tizen impl, api) |
| Eduardo Fullea |
|
Messaging, Telephony and Contacts form the set of key communication APIs to be dealt with in Phase 1 |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
5. Power Management API
summary | by responder | by choice
An API to manage the power consumption of the device, for instance by turning the screen on or off, putting the CPU in sleep mode, etc.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | |
| My organization is interested in helping to edit the specification for this API | 1 |
| My organization expects to provide an implementation report for this API | 1 |
| My organization expects to provide test cases for this API | 1 |
| My organization is interested in providing use cases for this API | 2 |
Skip to view by choice.
View by responder
Details
| Responder | Power Management API | Comments |
|---|---|---|
| Adam Barth | ||
| Jonas Sicking | I think this is a very low priority API since it's only really useful for a "window manager" or "desktop" application. Not useful for installed "apps". | |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO |
|
|
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr |
|
|
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API | |
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
6. Raw Sockets API
summary | by responder | by choice
An API to manipulate low-level connections (e.g. TCP, UDP), including the ability to listen for incoming connections.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 2 |
| My organization is interested in helping to edit the specification for this API | 2 |
| My organization expects to provide an implementation report for this API | 3 |
| My organization expects to provide test cases for this API | 2 |
| My organization is interested in providing use cases for this API | 2 |
Skip to view by choice.
View by responder
Details
| Responder | Raw Sockets API | Comments |
|---|---|---|
| Adam Barth |
|
|
| Jonas Sicking |
|
|
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr | ||
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
7. Telephony API
summary | by responder | by choice
An API to interact with the phone system, for instance to dial a number, pick up a call, route to voicemail, access the call log, etc.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 4 |
| My organization is interested in helping to edit the specification for this API | 3 |
| My organization expects to provide an implementation report for this API | 3 |
| My organization expects to provide test cases for this API | 2 |
| My organization is interested in providing use cases for this API | 4 |
Skip to view by choice.
View by responder
Details
| Responder | Telephony API | Comments |
|---|---|---|
| Adam Barth | ||
| Jonas Sicking |
|
We might be able to help edit, but I'm not sure. |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song |
|
Tizen Call API: https://developer.tizen.org/help/topic/org.tizen.help.web.api.device/tizen/call.html |
| Suresh Chitturi | ||
| Wayne Carr |
|
(Tizen impl, api) |
| Eduardo Fullea |
|
Messaging, Telephony and Contacts form the set of key communication APIs to be dealt with in Phase 1 |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
8. Accounts API
summary | by responder | by choice
An API to use existing, configured accounts and services, and for creating accounts of existing types.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 1 |
| My organization is interested in helping to edit the specification for this API | 1 |
| My organization expects to provide an implementation report for this API | 2 |
| My organization expects to provide test cases for this API | 2 |
| My organization is interested in providing use cases for this API | 2 |
Skip to view by choice.
View by responder
Details
| Responder | Accounts API | Comments |
|---|---|---|
| Adam Barth | ||
| Jonas Sicking | ||
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO |
|
|
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr |
|
|
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
9. Background Services API
summary | by responder | by choice
An API that enables a Web application to run in the background as a daemon.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 1 |
| My organization is interested in helping to edit the specification for this API | |
| My organization expects to provide an implementation report for this API | 2 |
| My organization expects to provide test cases for this API | 1 |
| My organization is interested in providing use cases for this API | 3 |
Skip to view by choice.
View by responder
Details
| Responder | Background Services API | Comments |
|---|---|---|
| Adam Barth |
|
We expect that we'll want to address these use cases as part of the runtime model. |
| Jonas Sicking |
|
We might be able to help edit, but I'm not sure. |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr |
|
|
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API | |
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
10. Bluetooth API
summary | by responder | by choice
A low-level API to interact with the Bluetooth hardware available on some devices.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 3 |
| My organization is interested in helping to edit the specification for this API | 2 |
| My organization expects to provide an implementation report for this API | 5 |
| My organization expects to provide test cases for this API | 3 |
| My organization is interested in providing use cases for this API | 3 |
Skip to view by choice.
View by responder
Details
| Responder | Bluetooth API | Comments |
|---|---|---|
| Adam Barth |
|
|
| Jonas Sicking |
|
We would be interested in this 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. |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song |
|
Tizen Bluetooth API: https://developer.tizen.org/help/topic/org.tizen.help.web.api.device/tizen/bluetooth.html |
| Suresh Chitturi | ||
| Wayne Carr |
|
(Tizen impl, api) |
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
11. Browser API
summary | by responder | by choice
An API that provides all the necessary items to build a Web browser. Most notably, this provides all that is needed in order to safely instantiate a viewport onto the open Web, pretend that such a viewport is the top level window even if the browser's chrome is itself written using Web technology, etc.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 2 |
| My organization is interested in helping to edit the specification for this API | 1 |
| My organization expects to provide an implementation report for this API | 3 |
| My organization expects to provide test cases for this API | 1 |
| My organization is interested in providing use cases for this API | 2 |
Skip to view by choice.
View by responder
Details
| Responder | Browser API | Comments |
|---|---|---|
| Adam Barth |
|
|
| Jonas Sicking |
|
|
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr | ||
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
12. Calendar API
summary | by responder | by choice
An API that enables complete management of the device's calendars.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 3 |
| My organization is interested in helping to edit the specification for this API | 2 |
| My organization expects to provide an implementation report for this API | 3 |
| My organization expects to provide test cases for this API | 2 |
| My organization is interested in providing use cases for this API | 3 |
Skip to view by choice.
View by responder
Details
| Responder | Calendar API | Comments |
|---|---|---|
| Adam Barth | We're interested in this 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, but I'm not sure. |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song |
|
Tizen Calendar API: https://developer.tizen.org/help/topic/org.tizen.help.web.api.device/tizen/calendar.html |
| Suresh Chitturi | ||
| Wayne Carr |
|
(Tizen impl, api) |
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
13. Contacts API
summary | by responder | by choice
An API that enables complete management of the device's address books.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 4 |
| My organization is interested in helping to edit the specification for this API | 3 |
| My organization expects to provide an implementation report for this API | 4 |
| My organization expects to provide test cases for this API | 2 |
| My organization is interested in providing use cases for this API | 5 |
Skip to view by choice.
View by responder
Details
| Responder | Contacts API | Comments |
|---|---|---|
| Adam Barth |
|
It's possible that we'd be willing to help edit this spec, but it's not a high priority for us. |
| Jonas Sicking |
|
We might be able to help edit, but I'm not sure. |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song |
|
Tizen Contact API: https://developer.tizen.org/help/topic/org.tizen.help.web.api.device/tizen/contact.html |
| Suresh Chitturi | ||
| Wayne Carr |
|
(Tizen impl, api) |
| Eduardo Fullea |
|
Messaging, Telephony and Contacts form the set of key communication APIs to be dealt with in Phase 1 |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
14. Device Capabilities API
summary | by responder | by choice
An API the discover the capabilities available to the device.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 2 |
| My organization is interested in helping to edit the specification for this API | 2 |
| My organization expects to provide an implementation report for this API | 3 |
| My organization expects to provide test cases for this API | 2 |
| My organization is interested in providing use cases for this API | 4 |
Skip to view by choice.
View by responder
Details
| Responder | Device Capabilities API | Comments |
|---|---|---|
| Adam Barth |
|
|
| Jonas Sicking | We have been hoping that feature detection as well as capability-features of individual APIs can fill the need for this API. For example the camera API should make it possible to detect which cameras the device has. | |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO |
|
|
| Jungkee Song |
|
Tizen System Information API: https://developer.tizen.org/help/topic/org.tizen.help.web.api.device/tizen/systeminfo.html |
| Suresh Chitturi | ||
| Wayne Carr |
|
(Tizen impl, api) |
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
15. DNS Resolution API
summary | by responder | by choice
An API for resolving DNS names.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 1 |
| My organization is interested in helping to edit the specification for this API | 1 |
| My organization expects to provide an implementation report for this API | 2 |
| My organization expects to provide test cases for this API | 2 |
| My organization is interested in providing use cases for this API | 1 |
Skip to view by choice.
View by responder
Details
| Responder | DNS Resolution API | Comments |
|---|---|---|
| Adam Barth |
|
This API isn't a high priority for us, but we have resources lined up for when this spec reaches the top of the agenda. |
| Jonas Sicking | ||
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr | ||
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
16. File System API
summary | by responder | by choice
An API that bridges the existing “File: Directories and System” API to the actual file systems known to the device.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 3 |
| My organization is interested in helping to edit the specification for this API | |
| My organization expects to provide an implementation report for this API | 3 |
| My organization expects to provide test cases for this API | 2 |
| My organization is interested in providing use cases for this API | 4 |
Skip to view by choice.
View by responder
Details
| Responder | File System API | Comments |
|---|---|---|
| Adam Barth |
|
This spec 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, but I'm not sure yet. |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO |
|
|
| Jungkee Song | Tizen Filesystem API: https://developer.tizen.org/help/topic/org.tizen.help.web.api.device/tizen/filesystem.html | |
| Suresh Chitturi | ||
| Wayne Carr |
|
(Tizen impl, api) |
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API | |
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
17. Idle API
summary | by responder | by choice
An API to be notified when the user is idle.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 1 |
| My organization is interested in helping to edit the specification for this API | 2 |
| My organization expects to provide an implementation report for this API | 2 |
| My organization expects to provide test cases for this API | 1 |
| My organization is interested in providing use cases for this API | 2 |
Skip to view by choice.
View by responder
Details
| Responder | Idle API | Comments |
|---|---|---|
| Adam Barth | ||
| Jonas Sicking |
|
|
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr |
|
|
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
18. Keyboard/IME API
summary | by responder | by choice
An API to support implementing virtual keyboards.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 1 |
| My organization is interested in helping to edit the specification for this API | |
| My organization expects to provide an implementation report for this API | 2 |
| My organization expects to provide test cases for this API | 1 |
| My organization is interested in providing use cases for this API | 1 |
Skip to view by choice.
View by responder
Details
| Responder | Keyboard/IME API | Comments |
|---|---|---|
| Adam Barth | ||
| Jonas Sicking |
|
|
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr | Is this needed in addition to Web Apps API? | |
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API | |
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
19. Network Interface API
summary | by responder | by choice
An API to manipulate the network interfaces (mobile, WiFi, etc.), such as listing available networks, current strength, etc. as well as configuring and enabling them.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 2 |
| My organization is interested in helping to edit the specification for this API | 1 |
| My organization expects to provide an implementation report for this API | 2 |
| My organization expects to provide test cases for this API | 2 |
| My organization is interested in providing use cases for this API | 2 |
Skip to view by choice.
View by responder
Details
| Responder | Network Interface API | Comments |
|---|---|---|
| Adam Barth | ||
| Jonas Sicking |
|
Though I would say this is a low priority to us. |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr |
|
|
| Eduardo Fullea |
|
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
20. Media Storage API
summary | by responder | by choice
An API to manage the device's storage of specific content types (e.g. pictures).
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 5 |
| My organization is interested in helping to edit the specification for this API | 2 |
| My organization expects to provide an implementation report for this API | 5 |
| My organization expects to provide test cases for this API | 3 |
| My organization is interested in providing use cases for this API | 5 |
Skip to view by choice.
View by responder
Details
| Responder | Media Storage API | Comments |
|---|---|---|
| Adam Barth |
|
It's not clear to us how this 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, but I'm not sure yet. How is this different from the File System API? |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
kinda skeptical of this given we have idb and file apis.. |
| Virginie GALINDO | ||
| Jungkee Song |
|
Tizen Media Content API: https://developer.tizen.org/help/topic/org.tizen.help.web.api.device/tizen/mediacontent.html |
| Suresh Chitturi | ||
| Wayne Carr |
|
(Tizen impl, api). Other comments are about difference from file api. this is more about media metadata for video, music, etc. and efficient search for media location based on that. |
| Eduardo Fullea |
|
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
21. Resource Lock API
summary | by responder | by choice
Prevent resources from being turned off (e.g. screen dimming, internet connection, CPU or GPU going to sleep mode).
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 1 |
| My organization is interested in helping to edit the specification for this API | 1 |
| My organization expects to provide an implementation report for this API | 2 |
| My organization expects to provide test cases for this API | 1 |
| My organization is interested in providing use cases for this API | 2 |
Skip to view by choice.
View by responder
Details
| Responder | Resource Lock API | Comments |
|---|---|---|
| Adam Barth | ||
| Jonas Sicking |
|
Hopefully we can help with editing, but I'm not sure yet. |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr |
|
|
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
22. Secure Elements API
summary | by responder | by choice
An API enabling the discovery, introspection, and interaction with hardware tokens (Secure Elements) that offer secure services such as tamper-proof storage, cryptographic operations, etc.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 1 |
| My organization is interested in helping to edit the specification for this API | 4 |
| My organization expects to provide an implementation report for this API | 2 |
| My organization expects to provide test cases for this API | 3 |
| My organization is interested in providing use cases for this API | 2 |
Skip to view by choice.
View by responder
Details
| Responder | Secure Elements API | Comments |
|---|---|---|
| Adam Barth | ||
| Jonas Sicking | ||
| Jérôme Giraud |
|
|
| Sylvain Lalande |
|
|
| Brian LeRoux |
|
generally impossible on mobile (no secure keystore on any platform yet really) but we can fake it w/ a server/auth hop |
| Virginie GALINDO |
|
|
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr |
|
|
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
23. Sensors API
summary | by responder | by choice
A low-level API to provide access to the device's sensors. Prior work from the Device APIs WG that was put on hold there will be transitioned to this group.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | |
| My organization is interested in helping to edit the specification for this API | 1 |
| My organization expects to provide an implementation report for this API | |
| My organization expects to provide test cases for this API | 1 |
| My organization is interested in providing use cases for this API | 2 |
Skip to view by choice.
View by responder
Details
| Responder | Sensors API | Comments |
|---|---|---|
| Adam Barth | ||
| Jonas Sicking | ||
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux | ||
| Virginie GALINDO | ||
| Jungkee Song | ||
| Suresh Chitturi | ||
| 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). |
| Eduardo Fullea |
|
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API | |
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API | |
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
24. Serial API
summary | by responder | by choice
A low-level API for interacting with serial ports.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 1 |
| My organization is interested in helping to edit the specification for this API | 1 |
| My organization expects to provide an implementation report for this API | 2 |
| My organization expects to provide test cases for this API | 2 |
| My organization is interested in providing use cases for this API | 1 |
Skip to view by choice.
View by responder
Details
| Responder | Serial API | Comments |
|---|---|---|
| Adam Barth |
|
This spec should be almost trivial once the working group agrees on the Raw Sockets API. |
| Jonas Sicking | Also a floppy disk API? ;-) | |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr | ||
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
25. Spellcheck API
summary | by responder | by choice
An API to perform spell checking, including dictionary and suggestions access.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | |
| My organization is interested in helping to edit the specification for this API | |
| My organization expects to provide an implementation report for this API | 3 |
| My organization expects to provide test cases for this API | 1 |
| My organization is interested in providing use cases for this API | 1 |
Skip to view by choice.
View by responder
Details
| Responder | Spellcheck API | Comments |
|---|---|---|
| Adam Barth |
|
|
| Jonas Sicking |
|
|
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr | ||
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API | |
| My organization is interested in helping to edit the specification for this API | |
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
26. System Settings API
summary | by responder | by choice
An API to manage the system's settings (including e.g. time/clock settings and personal preferences).
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 2 |
| My organization is interested in helping to edit the specification for this API | |
| My organization expects to provide an implementation report for this API | 2 |
| My organization expects to provide test cases for this API | 1 |
| My organization is interested in providing use cases for this API | 2 |
Skip to view by choice.
View by responder
Details
| Responder | System Settings API | Comments |
|---|---|---|
| Adam Barth | ||
| Jonas Sicking |
|
|
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr | ||
| Eduardo Fullea |
|
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API | |
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
27. USB API
summary | by responder | by choice
An API to interact with USB and USB storage devices.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 1 |
| My organization is interested in helping to edit the specification for this API | |
| My organization expects to provide an implementation report for this API | 2 |
| My organization expects to provide test cases for this API | 2 |
| My organization is interested in providing use cases for this API | 1 |
Skip to view by choice.
View by responder
Details
| Responder | USB API | Comments |
|---|---|---|
| Adam Barth |
|
|
| Jonas Sicking | We would be interested in this 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. | |
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO | ||
| Jungkee Song | ||
| Suresh Chitturi | ||
| Wayne Carr | ||
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API | |
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
28. Web Intent Registration API
summary | by responder | by choice
An API that makes it possible for Web Intent services to register themselves out-of-band (i.e without visiting a page declaring the Intent) with the browser and system.
Summary
| Choice | All responders |
|---|---|
| Results | |
| My organization expects to provide a proposed design for this API | 1 |
| My organization is interested in helping to edit the specification for this API | 1 |
| My organization expects to provide an implementation report for this API | 2 |
| My organization expects to provide test cases for this API | 1 |
| My organization is interested in providing use cases for this API | 4 |
Skip to view by choice.
View by responder
Details
| Responder | Web Intent Registration API | Comments |
|---|---|---|
| Adam Barth | We think this use case should be addressed in the manifest, which isn't yet on the agenda. | |
| Jonas Sicking |
|
|
| Jérôme Giraud | ||
| Sylvain Lalande | ||
| Brian LeRoux |
|
|
| Virginie GALINDO |
|
|
| Jungkee Song |
|
|
| Suresh Chitturi | ||
| Wayne Carr |
|
Web Intent Registration should include apps native apps on the local device that offer services, not just open web platform apps. |
| Eduardo Fullea |
View by choice
| Choice | Responders |
|---|---|
| My organization expects to provide a proposed design for this API |
|
| My organization is interested in helping to edit the specification for this API |
|
| My organization expects to provide an implementation report for this API |
|
| My organization expects to provide test cases for this API |
|
| My organization is interested in providing use cases for this API |
|
29. Additional deliverables
Are there any deliverables that you think are missing from the draft charted and should be added? If yes, please describe the purpose of the missing APIs as well as answering the same questions as above.
Details
| Responder | Additional deliverables |
|---|---|
| Adam Barth | |
| Jonas Sicking | |
| Jérôme Giraud | |
| Sylvain Lalande | |
| Brian LeRoux | I might even go so far as to say LESS deliverables in the first phase would be more pragmatic! |
| Virginie GALINDO | |
| Jungkee Song | |
| 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. |
| Eduardo Fullea |
More details on responses
- Adam Barth: last responded on 5, June 2012 at 20:08 (UTC)
- Jonas Sicking: last responded on 5, June 2012 at 21:52 (UTC)
- Jérôme Giraud: last responded on 6, June 2012 at 11:41 (UTC)
- Sylvain Lalande: last responded on 6, June 2012 at 11:42 (UTC)
- Brian LeRoux: last responded on 7, June 2012 at 16:54 (UTC)
- Virginie GALINDO: last responded on 8, June 2012 at 09:31 (UTC)
- Jungkee Song: last responded on 8, June 2012 at 10:07 (UTC)
- Suresh Chitturi: last responded on 11, June 2012 at 03:28 (UTC)
- Wayne Carr: last responded on 12, June 2012 at 20:53 (UTC)
- Eduardo Fullea: last responded on 13, June 2012 at 10:26 (UTC)
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project