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

Re: CfC: FPWD of Web Notification drafts

From: Drew Wilson <atwilson@google.com>
Date: Mon, 18 Oct 2010 11:06:12 -0700
Message-ID: <AANLkTikfJUa=Cno3ME73Awtx5XKBGgNPDherKFUe6NaT@mail.gmail.com>
To: Doug Turner <dougt@dougt.org>
Cc: Anne van Kesteren <annevk@opera.com>, Web Notification WG <public-web-notification@w3.org>
On Fri, Oct 15, 2010 at 9:56 PM, Doug Turner <dougt@dougt.org> wrote:

> I just skimmed the api. Here are my comments.  I'd like them discussed and
> have these issues tracked and resolved before moving to FPWD.
> On Oct 15, 2010, at 5:20 AM, Anne van Kesteren wrote:
> > This is a Call for Consensus (CfC) to publish these four drafts as First
> Public Working Draft[1]:
> >
> >  Web Notification Overview
> >  http://dev.w3.org/2006/webapi/WebNotifications/publish
> some of the use cases:
>  A calendar application alerts the user for an upcoming meeting, and
> allows the user to easily specify a "snooze" delay of several possible time
> periods.
>  An application with multiple simultaneous execution contexts (like a
> multi-tab email application) wants to show notifications without creating
> duplicate notifications.
> Are not possible today with system notifications, but they can be
> implemented using a callback.

Can you clarify? The latter case (replaceId) is definitely possible with
system notifications on Linux (NotifyOSD), and I don't see how similar
functionality can be achieved with a callback. Likewise, I'm not sure how
you would implement the former with a callback (I assume you're saying you'd
implement some kind of multi-step snooze interaction, where the user clicks
on a notification, then an HTML popup is displayed by the app which the user
can then decide whether to dismiss or snooze the notification)?

Once again, I think it's going to be difficult to make progress until we
come to some consensus around whether this API should be limited to "things
you can implement in Growl". Instead of having this discussion, we're
instead having proxy arguments about the validity of use cases (bi-di,
replaceId, HTML support) which I suspect would never come into question if
they had native Growl support.

> We should not use sync APIs EVER. permissionLevel should take a callback.
>  The implementation of this API probably will hit a database/datastore and
> we shouldn't block waiting for stuff like this.

I'm not entirely convinced about this. As an app writer, I can testify that
the ability to synchronously check for current permission levels is
extremely convenient. John, can you provide some feedback from the Qt WebKit
and Chromium implementations - do they require file I/O as part of their
current checkPermission() API?

 Web URL Notifications
>> http://dev.w3.org/2006/webapi/WebNotifications/publish/WebNotifications.html
> I think this is basically out of the scope of our charter as I read it and
> it is something I think Mozilla will *not* implement.

I can't state categorically whether URL notifications are in or out of the
scope of our charter, but I will note that NotifyOSD supports a subset of


Can you clarify why you believe that this is out of the scope of the

Received on Monday, 18 October 2010 18:06:42 UTC

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