- From: Drew Wilson <atwilson@google.com>
- Date: Mon, 18 Oct 2010 11:06:12 -0700
- To: Doug Turner <dougt@dougt.org>
- Cc: Anne van Kesteren <annevk@opera.com>, Web Notification WG <public-web-notification@w3.org>
- Message-ID: <AANLkTikfJUa=Cno3ME73Awtx5XKBGgNPDherKFUe6NaT@mail.gmail.com>
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 HTML: https://wiki.ubuntu.com/NotifyOSD#sanitizing Can you clarify why you believe that this is out of the scope of the charter? -atw
Received on Monday, 18 October 2010 18:06:42 UTC