W3C home > Mailing lists > Public > public-sysapps@w3.org > June 2012

Re: Deliverables

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 3 Jun 2012 21:20:21 -0700
Message-ID: <CA+c2ei9zpz2iLzW5UNrzOS8KSbtG2Z7iPoX9kfRrejY+xPnxJA@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 June 2012 04:21:21 GMT