W3C home > Mailing lists > Public > public-web-notification@w3.org > October 2010

Re: Publishing Web Notification Drafts

From: Drew Wilson <atwilson@google.com>
Date: Wed, 13 Oct 2010 10:15:31 -0700
Message-ID: <AANLkTi=0Dz3570OjubhdWdMxLeOJ9R6XSEzkDwYaMVme@mail.gmail.com>
To: John Gregg <johnnyg@google.com>
Cc: Anne van Kesteren <annevk@opera.com>, Doug Turner <dougt@dougt.org>, Web Notification WG <public-web-notification@w3.org>
Overall this looks good. A few comments:

1) To address Doug's earlier comment about dropping things like "dir" and
"replaceId" - I'd be concerned about omitting these. The use cases around
"dir" seem fairly well established, and replaceId likewise seems strongly
grounded in use cases and is already supported by some system platforms (I
believe growl supports this, no?). I'd like our API to be driven by our use
cases and requirements, and not by the functionality exposed by any specific
current system platform, as the latter may change over time at the whims of
various development teams.

2) I took a quick look at the Feature Permission spec and it mostly looks
reasonable. I would suggest getting rid of the privilegedFeatures attribute,
in favor of having permissionLevel() return an UNSUPPORTED return value for
any features that are not supported by a given platform. Otherwise,
developers would have to manually walk the privilegedFeatures array looking
for various string attributes before calling any permissions APIs, which
seems inelegant. Is there any reason why the full list of potential features
should be exposed to the developer?

3) This might be more than we want to bite off right now, but one concern
people have had about HTML5's permission model is it requires the developer
to request one permission at a time, leading to a sequence of info
bars/permission dialogs as the user is serially prompted for things like
geolocation access, extra DB quota, notifications, etc. If we are defining a
general-purpose permissions API, it might be useful to allow the developer
to pass an array of features to requestPermission(), which the user agent
could potentially consolidate into a single permission grant UI flow.


On Wed, Oct 13, 2010 at 12:51 AM, John Gregg <johnnyg@google.com> wrote:

> http://dev.w3.org/2006/webapi/WebNotifications/publish/ now contains
> the multi-part spec, the parts being:
> - Feature Permissions - A specification for providing permissions for
> specific features such as notifications.
> - Web Notifications - A specification for displaying simple
> notifications with text and icon content.
> - Web URL Notifications - A specification for displaying Web
> notifications with content provided by a URL.
> The latter two contain subsets of the original one-part spec largely
> unmodified except for the addition of references to the other parts.
> Common material like definitions and use cases I have left in the
> Overview document.
> The Feature Permission spec has more new content, as it takes the
> permissions notion previously described for notifications and makes it
> in a generic system which could be used by any "privileged feature" of
> a user-agent.  What does the group think about that?
> Thanks,
>  -John
Received on Wednesday, 13 October 2010 17:16:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:13 UTC