Re: Rechartering Device APIs & Policy Working Group

On Tue, Feb 8, 2011 at 1:42 PM, Rich Tibbett <rich.tibbett@gmail.com> wrote:

> This initial proposal looks good. Here are some thoughts on the proposed
> charter:
>
> - We still need to define the scope of the deliverables (Section 3) a bit
> better. We have quite a number of deliverables on the list. We want to get
> these things implemented and having a laser focus on things that are
> implementable might be a really good start. Also, we have to keep things as
> simple as possible. For example, instead of jumping straight to generic
> events there's a lot of value in specifying well-defined sensor events
> initially). Below are some thoughts per item on the charter.
>
> Section 3:
>
> Work items that I would really like to see included in the charter:
>
> A1. Sensor Events: reworking the System Info API to a set of well-defined
> sensors based on reusing the events model of the Orientation API ().
> Initially focused on a well-defined list of sensors (such as termperature,
> light, proximity, noise, pressure, etc) and then potentially exploring
> extensibility and sensor discoverability as a future work item.
>
> A2. Media Streaming: the DAP activity should pick up some of the slack from
> this RTC-Web initiative and/or coordinate with the RTC-Web initiative on
> additional specifications required. Actually, it's going to be important to
> clearly delineate the RTC-Web and DAP deliverables but DAP has a significant
> part to play in this work.
>
> A3. HTML Media Capture: let's continue to move the HTML Media Capture spec
> through the W3C process: http://www.w3.org/TR/capture-api/
>
> A4. PIM APIs (minus tasks). These are intended for more longer term
> consideration and implementation. I don't expect full browser support while
> browser vendors are still focused on implementing more prioritized HTML5
> features. We can also do a number of things without implementing the full
> API in lack of widespread support. However, it may be possible to move these
> through the W3C process based on implementations that we already have and
> other implementations that will come online during the chartered term.
> 'Tasks' seems to be a very low priority compared to Contacts, and to a
> lesser extent, Calendar.
>
> A5. Context Menus API: The ability to create menus that apply to defined
> user agent contexts (e.g. address bar menus, right-click menus for
> images/video/text, speed dial menus, etc). An example of the type of API in
> mind is available here:
> http://www.opera.com/docs/apis/extensions/backgroundprocessguide/#bp23.
> Opera also have a full W3C-style specification ready to go for kicking off
> this work (if it gets adopted in to the charter).
>

I forgot to add an additional item:

A6. Intents, Activities and Services: Providing a generic intents model for
starting device or cloud based activities and services. Essentially this is
a proposal to model the Android Intents, Activities and Services model for
the web (incorporating and building upon the work of web-send.org).


>
> Work items that I don't think we should put in to our charter initially due
> to implementation concerns (interface, technical, political):
>
> B1. Messaging API: we have sms, mmsto and mailto URIs that are sufficient
> for adding messaging in to our products without the need of an additional
> API. In the future we could look at developing extensions to e.g. XHR for
> advanced messaging features (success/error callbacks, attachments) but this
> is not the initial priority. The first step is to integrate communication
> services in to browsers and we don't need a new API for this purpose.
>
> B2. Capture API: The jury is still out on whether its necessary for a web
> app to be able to programmatically capture audio, video and images from a
> user's device. The UI for these interactions is a little painful and we have
> other methods (e.g. the HTML Media Capture spec for this purpose).
>
> B3. Application Launcher API: Custom URL schemes and URL resource mime
> types launch native apps, not APIs.
>
> B4. Communication Log API: I can't find any significant use cases for
> providing the communication log to web apps. If necessary, a communication
> log can be uploaded by the user as a file or mounted via the File System API
> for the web app to access.
>
> B5. Gallery API: Both the File API and File System API promise to deliver
> functionality similar to this proposal. It's not core enough to get wide
> implementation IMO.
>
> Work items that might be potential work items to live under the new
> charter:
>
> C1. File System API: While file system fits well in the WebApps group, the
> File System API is really suited to fall under our charter.
>
> C2. HTML <device>: Initially incubated on the DAP mailing lists (with
> Hixie), it might be nice to push forward development of this stuff in W3C
> via DAP (though see my discussion on the relationship of the new DAP group
> with the RTC-Web initiative above). FWIW, this is not specified in the W3C's
> HTML5 snapshot since it is a current work item in WHATWG. It might be nice
> to give <device> a home in W3C DAP (or coordinate how that will work with
> the RTC group if/when it gets chartered).
>
> Other comments on the charter proposal:
>
> - Remove the requirements for the delete paradigm from our APIs. Simply, we
> have yet to work out a way to represent delete in the UA while additional
> non-web interfaces, such as management consoles and configuration windows,
> are a much better way to provide delete functionality that the user
> controls.
>
> - We don't need to publish a Working Group Note on the Design Patterns that
> we choose (included in Section 3.2: Other deliverables). Design Patterns
> vary depending on the problem put in front of us. There is likely not a
> single design pattern for all of our deliverables.
>
> That's it for now. Any feedback is appreciated.
>
> - Rich
>
>
> On Wed, Feb 2, 2011 at 3:09 PM, Dominique Hazael-Massieux <dom@w3.org>wrote:
>
>> Hi,
>>
>> The current charter [1] of our Working Group will expire at the end of
>> June this year; it is pretty clear that our work will not be done by
>> then and thus will need to extend or renew our charter.
>>
>> Given that our understanding of the work that needs to be done has
>> evolved quite a bit, and also due to the lack of involvement of
>> potential implementors of our work in the group, the Chairs and Staff
>> Contacts are suggesting that we should try to refine our charter and
>> have it reviewed by W3C Advisory Committee.
>>
>> To that end, I've been working on a proposed new charter for the group:
>> http://www.w3.org/2010/11/DeviceAPICharter.html
>>
>> This charter introduces several important changes — which are all up for
>> discussion.
>>
>> The most important change is the removal of the Policy Framework as a
>> deliverable of the group. That proposed change is motivated by the
>> following reasons:
>> * the work has only had limited traction in the group so far,
>> * the policy framework is architecturally independent of the APIs, while
>> its bundling with our work on APIs has been the source of
>> misunderstandings from potential implementors.
>>
>> To reflect the removal of the said framework, we're proposing to rename
>> the group to "Device APIs Working Group" — although the group would
>> still be referred as DAP since that's now a well-known moniker.
>>
>> The removal of the Policy Framework doesn't mean that the group would
>> stop working on security. On the contrary, the new charter puts a strong
>> emphasis on the needs surrounding security and privacy (privacy which
>> was actually missing from the previous charter.) We've already received
>> feedback that the current wording around security isn't satisfying and
>> welcome proposed changes to the text.
>>
>> Finally, the new charter tightens the scope of our APIs to reflect the
>> ones we've actually been working on — the very broad scope of our
>> current charter has been an explicit showstopper for some W3C Members to
>> join the group.
>>
>> You can see a diff between the two versions of the charter at:
>> http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2009%
>> 2F05%2FDeviceAPICharter&doc2=http%3A%2F%2Fwww.w3.org%2F2010%2F11%
>> 2FDeviceAPICharter.html<http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2009%2F05%2FDeviceAPICharter&doc2=http%3A%2F%2Fwww.w3.org%2F2010%2F11%2FDeviceAPICharter.html>
>>
>> We very much welcome feedback and suggestions on this new charter, which
>> will also be discussed during our F2F in Seoul.
>>
>> Dom
>>
>> 1. http://www.w3.org/2009/05/DeviceAPICharter
>>
>>
>>
>>
>