Introducing DAP

Introduction proper

Before getting to the meat of DAP — most of which is in following posts anyway — I'd like to give a very brief overview of what it is in terms of a working group. I find that people are often intimidated, or befuddled, or both, by W3C working groups. There's no point in being intimidated: it's just a bunch of geeks who happen to write specifications. Befuddled, dazed, confused — at times I can certainly understand. There's a big pile of jargon and process involved in standards. After years of working in this space, and having worked with several other standards organisations, I tend to think that a lot of that process is useful (and the W3C's is certainly one of the most useful, by a large margin). The problem is that people get exposed to it before they have a chance to see how it might help, which is a bit like having a hammer thrown into your face before you get a chance to realise you're holding a nail. I'll won't go into details, but if you want to skip over at least remember this: DAP is open for participation on its mailing list to everyone, and you don't need to read the process to jump in.

DAP stands for Device APIs and Policy. It is a W3C working group, which is to say a bunch of people working together to get some hot open technology out. It's a public working group, which means that we do all of our work in the open, and that anyone can sign up on the mailing list and start contributing. If you want a feel for the volume of traffic you can look at the archives.

My role in the group is to chair it, or rather co-chair it alongside Frederick Hirsch who's one swell guy. The Chair is nothing special, and it certainly doesn't give one a larger voice let alone make one smarter than other contributors. We're just there to try to enforce a modicum of sanity where the W3C Process is concerned, and to open our mouths when people aren't talking enough. That doesn't mean we don't have technical opinions either, but we're expected to show a little restraint in the flame war department.

DAP was created in August 2009, you can consult the charter if you're into details but it's not fascinating. Initially, there was some interest in DAP being the same as the WebApps WG (which does cool stuff like XMLHttpRequest, Widgets, local databases, etc.) but for various reasons — notably that WebApps is doing a lot of stuff already — it was decided to work separately (though we coordinate of course). It was also suggested that we could swallow the Geolocation WG (which shockingly enough does Geolocation) but they were working fine overall so disruption didn't seem useful.

The mailing list has ~250 participants, not all of whom are active of course. It covers a lot of people and companies in the Web and mobile domains.

What we're doing

If you've looked at the charter you've seen the list of things people thought we'd be doing. Here's the list of things we've actually worked on, or plan to work on soon. Note that the group's home page will always have the most up to date information. It's a large bunch of documents, but don't worry: you can still participate even if you're only interested in one or two of them. They are by and large orthogonal to one another.

Contacts (read-only) and Contacts (writeable)

The Contacts API provides access to the user's unified address book, which is to say that the implementation may use multiple sources (e.g. the local address book, several of social networks) to expose a single, and simplified view over the user's contacts. The reason that it is split into read and write variants is because the latter is a lot harder, and will require more work (but more on that in a future article — note that other APIs on this list may be split as well). This is a rather advanced draft, with an implementation in the works from Mozilla.

Calendar

The Calendar API is meant to expose a rather rich data model over unified calendars (so, again, local or remote). It is also reasonably advanced though we have a number of internationalisation issues to handle. It may also get split into multiple layers.

HTML Media Capture and Media Capture API

These two interfaces cover capturing pictures, audio, and video from what input devices may be available. The first one covers integration with <input type='file'/> so that it may trigger the UI for such capture with minimal extra syntax and only a small extra API. The second one provides for more advanced, and more complex, access to such input devices.

Messaging (SMS, MMS, email)

The Messaging API is currently able to send various message types, but also to be notified of when they are received. The group is currently discussing the exact scope that this specification needs to have, how much of it makes sense in a browser context and if it might need to get trimmed down. I'll come back to these topics later.

System Information

This is a reasonably mature specification that describes how various properties of the system can be exposed to script. This includes things like CPU, heat, ambient luminosity and sound, network access and a number of other aspects.

Gallery

Gallery describes a way of providing access to one's locally stored media, with a lesser level of risk than providing direct file system access would produce. The current draft doesn't reflect what the group wants to do with it, which is to model it after Contacts once we are happy with the latter's model. The reason for this is that in terms of privacy, security, and UI metaphors they are very similar.

Policy Framework, Policy Markup for Device APIs, Device API Features,

Policy is the whole system that guards access to certain API functionalities. At this point the thinking about policy is still in flux because we are still figuring out the best angle. Policy could be used as a system to grant certain web applications (or widgets) access to functionality that would normally be dangerous based on some trust. That trust could come from from the phone operator with which you're using your phone (if that doesn't make your foam at the mouth) just as well as from some manner of socially networked web of trust. To be honest, a lot of people think that policy should just die, and given the pace of the work and the pressure against it that seems like a distinct possibility.

Privacy Requirements and Privacy Ruleset

As you may have noticed, a lot of the APIs on our plate are likely to have a strong impact on privacy. That's why DAP is working actively in this domain, not only with each API having carefully thought out privacy-by-design architectures but also on specific, more global privacy solutions.

Powerbox

The Powerbox is a (not yet put online) proposal from Google for a secure and user-controlled way of making third-party services available to Javascript. It has very interesting properties, and security-wise it compares favourably to OAuth.

The <device> element

Formally this element is not part of DAP, but there has been talk that it might be. I will be coming back to it either way as it is rather interesting.

It used to be that both File API: Writer and File API: Directories and System were developed in DAP, but we moved them over to WebApps. I'll still be talking about them anyway.

How to participate

If you're interested in participating, you are very much welcome. The simplest thing that you can do is to pick a draft that you're particularly interested in, read it, and send email with your feedback. You can also sign up to the mailing list and enter the various discussions. And if there's a feature you like, as usual, blog about it, tweet about it, talk to your favourite browser vendor about it, bitch to us about what you don't like, etc.

Watch this space for more, and come hack some cool specs with us!

Table of Contents

• Introducing DAP (Hebrew translation and other Hebrew translation)
• A New DAP
• Trusted Web Applications Considered Harmful
• Numerical Constants Must Die
• Application-Level Menus for HTML