W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2010

Re: Updated Features draft

From: <Frederick.Hirsch@nokia.com>
Date: Wed, 15 Sep 2010 14:57:41 +0200
To: <dom@w3.org>
CC: <Frederick.Hirsch@nokia.com>, <public-device-apis@w3.org>
Message-ID: <851DB729-CA5B-4808-BCEA-EEB70C93B21F@nokia.com>
maybe we should first as a group decide about capabilities before you remove them entirely.

regards, Frederick

Frederick Hirsch

On Sep 15, 2010, at 8:53 AM, ext Dominique Hazael-Massieux wrote:

> Le mercredi 15 septembre 2010 ŗ 00:32 +0200, Frederick.Hirsch@nokia.com 
>> Thus the architecture simplifies to the following:
>> 1. Identified APIs (or all APIs)
>> 2. trust domains
>> 3. capabilities allowed for each trust domain, either across all APIs or on a  per-API basis
> Iím not convinced that we even need (3) at this point; Iím not quite
> sure what this would buy us, especially as I donít think any browser
> currently deployed use that sub-level framework, and that W3C Widgets
> donít refer to them either.
>> This  corresponds to the Nokia contribution.
> Looking at Nokiaís security framework for widget runtime engines:
> http://wiki.forum.nokia.com/index.php/Widget_Platform_Security
> it looks like the capabilities are very coarse (e.g. lumping together
> any kind of ďuser dataĒ), which wouldnít match what we have currently
> defined in our APIs, and would in fact go against our minimalization
> approach.
> I think that this defect is likely to happen for any sub-API granularity
> (which I understand capabilities are).
>> So, I'm ok with the simplification of not referring to features and
>> focusing on trust domains + capabilities + API naming (method + class
>> name I assume).
>> I'd be interested whether Paddy and Laura agree.
>> It would be great in my opinion if you can take another pass.
> Iíll take a stab it (hopefully this week), but be warned that
> capabilities may be a casualty in that process :)
> Dom 
Received on Wednesday, 15 September 2010 12:58:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:46 UTC