Re: Notifications

Following up on breaking out createHTMLNotification() and
createNotification() vs combining them into one large API - I believe the
intent is that a given user agent may not support all types of notifications
(for example, a mobile phone application may only support text + icon
notifications, not HTML notifications). Having these APIs broken out
separately allows the UA to communicate whether it supports one or the other
to the web app (a UA that does not support HTML notifications would leave
createHTMLNotification() undefined).

-atw

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.
>
>
>> 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.
>
>
>>
>> How does create(HTML)Notification actually work.
>> At which point does it load the external resources?
>>
>> At which point is "display" event dispatched?
>> When showing the notification? But what if the external
>> HTML file or icon file isn't loaded yet?
>>
>
> I will make this more specific in the draft: create[HTML]Notification
> should not load the necessary resources until it is about to be displayed
> (in case of a queue).  Once it is at the top of the queue, it should:
>
> - load its resources as if opening a new window
> - dispatch the display event
> - show itself on the screen
>
>
>>
>> "The function provided in the callback parameter will be invoked when the
>> user has responded to the permission request. "
>> The IDL doesn't show any callback parameter.
>>
>
> Quite right -- will fix.
>
>
>