- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 3 Jun 2012 21:20:21 -0700
- To: Adam Barth <w3c@adambarth.com>
- Cc: public-sysapps@w3.org
On Thu, May 24, 2012 at 9:22 AM, Adam Barth <w3c@adambarth.com> wrote: > Hi public-sysapps, > > Before we start on technical work, we should make sure we'll all happy > with the charter. One concern I have with the draft charter > <http://www.w3.org/2012/05/sysapps-wg-charter.html> is that the list > of deliverables is too long. I'm worried that this group wouldn't > have sufficient resources and momentum to write 28 high-quality > specifications right out of the gate. By way of comparison, the > WebApps charter has 16 deliverables and has significantly more > resources and momentum than we do. > > Concretely, I think we should pick a handful of deliverables to work > on in the near term and then add more deliverables as we build up > momentum and success. For example, here's a set of deliverables that > might make sense for the first round: > > * Security Model > * Execution Model > * Raw Socket API > * DNS Resolution API > * USB API Jumping in late here. I absolutely agree that we should focus on a small set of specifications first. Even if we have people step up and offer to edit specifications we have limited bandwidth in how many specifications we can review and provide implementation feedback on. I care less about which exact specifications we start with though. But I think the Security Model and Execution Model is definitely something we should start with. Until we have those nailed down, very few of the other specifications can be fully specified since most of them provide higher degree of access than traditional web APIs, and we need to define how to do that securely. The only API that I have an opinion on that we *should* include is what we at mozilla has referred to as "system messages API". This is an API which is used to deliver messages from the UA to a application, even when that application isn't currently running. I.e. the system messages API will deliver the message to the application, but if the application isn't running, the API first starts the application and then delivers the message. This is a capability we have found the need for in several APIs, such as the Alarm API, WebIntents/WebActivities and Push Notifications API. This is why I'd recommend that we include this in the initial set, possibly along with an API which would use this mechanism. Beyond that I think I'm ok with any set of specifications, as long as we keep the number small. / Jonas
Received on Monday, 4 June 2012 04:21:20 UTC