W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2012

Re: System Level APIs draft proposal

From: Robin Berjon <robin@berjon.com>
Date: Fri, 4 May 2012 12:09:26 +0200
Cc: "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <47C240CA-03F4-460A-9CEE-0088430FE0D7@berjon.com>
To: Doug Turner <dougt@mozilla.com>
Hi Doug,

On May 2, 2012, at 18:31 , Doug Turner wrote:
> I agree.  I think it should be left up to the UA to figure out how to express what is browser-safe and what is non-browser-safe.  We should have non-normative language that expresses that certain api need security and privacy considerations.  However, I think the WG should steer away from mandating what APIs are really 'browser-safe'.

The point isn't about mandating that browsers can never implement this or that API. Rather, it's about organising the work. Given the current state of the browser security model, there isn't a way (that I know of at least) to make navigator.fileSystem.format() safe. I know I wouldn't want to use a browser in which that would sit behind a "This site would like to format your hard drive: [Accept] [Deny]" doorhanger :) I don't think you'd want to ship it, either.

We can't preclude that we'll eventually come up with a way of making that possible, but in the meantime we have to start somewhere, and try to organise the work in a manageable fashion.

Think of it as approaching the question of defining APIs for Web applications from both ends. At one end we put stuff that we know for sure can be made safe in a browser. At the other end, we put stuff that for the time being we can't make safe in a browser. This distinction is useful because the design for the APIs tend to be different, and because the people implementing them can be different. It means we can get organised and start working. If we figure out a way to merge the two, then all the better.

I think that I'll soften the language about excluding browser-safe stuff  I've received several proposals in this direction.

> One of my complaints of the DAP was that it was a wide sweeping WG that had way too many deliverables.  I tend to think smaller WGs with tighter focus work a lot better.  Spawning off a WG to work specially on System Level APIs seems like it is a good thing.  However, I am not sure about all of the politics of something like that.

The problem isn't so much politics as resources and organisation. A large sweeping group is actually more flexible because if people participating in it want to work in smaller teams it's trivial (almost zero overhead) to create task forces for that purpose and more easily organised because all that's shared (e.g. face to face meetings) is naturally coordinated. Trying to get a bunch of small groups to meet at the same place and time is painful, and doing joint work across groups can be quite painful.

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Friday, 4 May 2012 10:09:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:37 UTC