Re: Rechartering Device APIs & Policy Working Group

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

> 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 (
>>
>
http://dev.w3.org/geo/api/spec-source-orientation.html


> ). 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.
>>
>
I meant to say 'While file *writer* 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
>>>
>>>
>>>
>>>
>>
>