Robin Berjon

DAPdate Zero

Introducing DAP

There are many ways of getting someone to do something that you would like them to. You can ask nicely, you can put a gun to their head, you can wallow in the dust and kiss their boots. You can turn on your irresistible Bambi eyes and stare until you prey can only give up. The latter is my personal superpower, but that's not what brings us together today. What brings us together, on this page, at this instant, is Bruce Lawson.

From obsequious invitation to brutal coercion, there is no trick that Bruce masters not and no shame to stop him. Clearly not content with pestering me about blogging on DAP over Twitter, he deployed his signature treachery during the (excellent and highly recommended) Over the Air conference to ask the audience to up his Twitter pestering by crowdsourcing it. Had I been there I may have been able to stop him (with the Bambi eyes), but this tricksy villain bested me by abusing the fact that I was then busy travelling from Oxford (where the also excellent and equally highly recommended XML Summer School was taking place) to London.

When I checked in at the Over the Air registration desk, one of the people handling it saw my name and exclaimed OH MY GOD!!! You're Robin Berjon! Some dude this morning totally blasted you on stage about not blogging about DAP. Man, you're just gonna have to write that blog! True story.

With great apprehension I then proceeded to open up my laptop and look at my Twitter mentions. No doubt, a genuine avalanche had submerged me. You win this time Bruce Lawson!

But anyway, in bitter defeat I have to admit that Bruce has a point. Every time I go to developer events and talk about DAP, I note two things:

  1. there is a huge amount of interest in what DAP is doing; and
  2. no one is remotely aware that we even exist in the first place.

This needs to end! I therefore hereby pledge to post regularly on this blog about what DAP is doing, what problems we're facing, what approaches we're taking, etc. I'll maintain a list of links at the bottom of this page to all the other posts that mention DAP, just to keep a nicely ordered ToC (just as I did for XML Bad Practices). If you want feed updates, pick the English tech feed (unless you also want non-tech and French posts of course, see the sidebar for options). And of course I'll notify through Twitter. I'll be calling these "DAPdates". Yes, it's a terrible name.

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

This is the list of other articles in this series.