[WebNotifications] omnibus feedback reply, new draft

I've posted a new editor's draft of the notifications spec.  It
addresses the comments made on the previous spec (inline below,
duplicate comments removed), and adds the following new pieces which
were also suggested in other threads.

* dir attribute which allows the directionality of the notification

When the notification is web content, this is not important as the
directionality can be specified internally; for text+icon
notifications, the directionality indicates how the content should be
passed to the notification platform.

* replaceId attribute which allows notifications to be replaced.

The use case for the replaceId is multi-tab web applications.
Currently specified, it is easy to produce unwanted duplicate
notifications for the same purpose (e.g., the same meeting reminder),
and difficult to avoid except by using something like shared workers
as a point of synchronization.  Using a replacement ID means that
duplicates cancel each other out cleanly, and also allows in-place
updates.  This functionality is supported natively by libnotify, and
can be simulated on other platforms by closing and opening.

Feedback, especially on these new additions, is appreciated.

Thanks,
 -John

On Tue, Mar 23, 2010 at 3:33 AM, Anne van Kesteren <annevk@opera.com> wrote:
> The Web IDL should be cleaned up:
>
>  * There is no such thing as DOMWindow
>  * Supplemental interfaces should use [Supplemental]

Cleaned these things up.

> The methods should raise some kind of exception when there is something
> wrong with the URL argument. See e.g. the open() method description in
> XMLHttpRequest.

Added this.

> It would be nice if fetching of resources was described in terms of the
> fetch algorithm from HTML5.

Added this reference and changed the language to match.

> Currently there are no processing requirements for the mime argument of
> createWebNotification(), do we really need it?

I've removed the MIME type.

> Queuing should be defined in terms of the HTML5 event loop.

I'm not sure this makes sense.  Queueing for notifications takes place
outside of the script execution context, much like the timer queues
where the spec defines an abstract list of pending timers that return
to the event loop when they expire.  I think notifications are the
same way: there's an abstract queue which returns to the event loop
when space is available. I've tried to make this more clear in the
spec.

> Should we really put another interface on the global object? Can we not put
> these on window.navigator like other APIs that integrate with the system
> layer?

I moved it to the navigator object.

On Tue, Mar 23, 2010 at 10:16 AM, Drew Wilson <atwilson@google.com> wrote:
>
> Section 4:
>
> The definition of the onclose attribute is incorrect, and should read "An event listener function corresponding to the event type 'close'", not 'error'.

I've fixed the typo.

>
> Section 5:
>
> I'm wondering if the documentation for requestPermission() should read: "If the current permission level is permission_denied, the user agent *must* take no action..." (rather than "may take no action").

I don't think we should specify that explicitly, but rather leave room
for implementation experience to guide whether this should be guided
by heuristics or by a single rule.  I can imagine situations where
these permission settings get stale or a user doesn't know how to
configure them; if there is no way to ever be prompted again, this
could be quite limiting.

> Is the intent of the spec that an Exception is thrown if the user calls requestPermission() when the permission is already PERMISSION_ALLOWED?

That was not my intent.  If the request for permission can be
satisfied with no action, I think the method should just return and
call the callback immediately.

> Section 8:
>
> Should passing an unsupported type of web content to createWebNotification() generate an error event?

I think it should throw an exception.  Since there is no Notification
object yet to target, an error event doesn't make sense.

> The "display" event is generated when the notification is passed along to the underlying notification platform - technically, since the underlying platform can also do its own queueing, it's possible that the display event is generated before the notification itself is displayed. Should this be mentioned in the spec?

I added text which makes this explicitly clear.

> Section 9:
>
> Is there any use case where an application needs to know that the system has closed the notification without user input? Currently a close event is only generated if the user explicitly dismisses a notification.

The close event should be fired for all methods of closing.  I've
added text to that effect.

Received on Thursday, 22 April 2010 19:18:28 UTC