Re: Rechartering Device APIs & Policy Working Group

Hi Richard,

thanks for your feedback, some notes below.

On Feb 8, 2011, at 13:42 , Rich Tibbett wrote:
> 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.

Since I think that this discussion is essentially technical, I think we should have it run in a separate thread and see what plan we can cook up based on that.

> 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.

We will certainly be coordinating with RTC, but I don't think it's fair to say that there's slack to be picked up before they've had a chance to start :)

> 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/

I hope no one was objecting to this!

> 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.

I think we should keep them as is. We've done good work. It's okay if they sit in LC/CR for a while as we wait for implementations. I don't know if Tasks is all that lower-priority, but it's pointless to work on it until we've addressed the issues with Calendar I think.

> 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).

So this is essentially a split from UI. Definitely interesting.

> 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.

Actually the API that we have is nice, does something small and simple, and works. It provides a better experience than mailto and friends. It's pretty simple to implement, and it's secure. I don't think that Apple added it to iAd JS because they thought it sucked, and I agree with them. I wouldn't kill to have this, but I certainly like having it.

> 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).

That's not enough to rule it out. I think that we should keep it and look into finding a way of making it work that flies. I've been looking at forking Rainbow for precisely this sort of experimentation.

> B3. Application Launcher API: Custom URL schemes and URL resource mime types launch native apps, not APIs.

That doesn't give you what intents and introducer give you. How about changing the name and making the scope fit the Web?

> 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.

What has changed since the decision to move it there to justify this reversal?

> 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).

I think that <device> is firmly in RTC's remit. If RTC doesn't get chartered, I'm very much in favour of having that work item done in DAP though.

> - 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.

I think that we should keep it in, but allow ourselves to ship without it. We need to keep the door open to smart ideas if they turn out to be possible.

> - 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.

Yeah, that one can go.

-- 
Robin Berjon - http://berjon.com/

Received on Wednesday, 9 February 2011 12:57:33 UTC