Re: Notifications

On Wed, Feb 3, 2010 at 10:33 AM, John Gregg <johnnyg@google.com> wrote:

> On Wed, Feb 3, 2010 at 9:55 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:
>
>> Hi all,
>>
>> some random comments about
>> http://dev.w3.org/2006/webapi/WebNotifications/publish/
>> (I didn't know that the draft existed until the link was mentioned
>>  in an email to @whatwg mailing list :/ )
>>
>
> Hi Olli,
>
> I was hoping to get some more work in on the draft before officially
> sending it out for feedback, but since there is interest out there it's time
> to start ramping it up.  Thanks for the comments!
>
>
>> NotificationCenter is a bit strange. Why do we need
>> a separate interface for this?
>> I'd rather added createNotification to window object,
>> or to .screen.
>>
>
> The idea was to have a common place to manage notification permissions as
> well as create notifications.  That would end up with a lot of
> notifications-specific items on the window object.
>

Agreed.  And there is precedent for this.  (AppCache, WebStorage, IndexedDB
I know off the top of my head.)


>  createNotification and createHTMLNotification could be
>> merged. Based on the parameters UA could create
>> a bit different kinds of notifications.
>> Or depending on what kind of resources get loaded.
>>
>> PERMISSION_NOT_ALLOWED vs. PERMISSION_DENIED
>> The naming should be better.
>> Maybe PERMISSION_UNKNOWN and PERMISSION_DENIED ?
>>
>
> That sounds reasonable to me, I'll make that change.
>
>
>> requestPermission talks about user gesture, but doesn't
>> define what an user gesture actually is.
>>
>>
> I thought the term was well known, but I will find a suitable reference.
>
>
>> If createNotification would be in
>> .screen or in window, then perhaps rename other methods to
>> .requestNotificationPermission()
>> and .checkNotificationPermission()
>> those are a bit long ones, but still shorter than
>> .notifications.requestPermission()
>>
>
> As mentioned above, I think it's a good trade of 2 extra characters to put
> these things in a common place; it also makes it more easy for an author to
> check "if (window.notifications === undefined)".
>
>
>>
>> Why the need for notifications in a worker?
>> In which screen would the notification show up?
>> I would leave that out of the draft.
>> Worker can easily send some message to window to
>> ask for a notification.
>>
>
> The thought is that a shared worker would be a good place to generate
> notifications for a multi-tab application, while avoiding duplicate alerts.
>  If we require it to find a window, it has to keep track of which windows
> are open.  As that set may change, I don't think it's as easy as allowing
> direct access to the API.
>

Agreed.  Having a shared worker that doesn't need to worry about races with
shutting down windows seems like a big win.

Olli, do you foresee any problems with allowing access from workers?