Hi WebKit! I am interested in refactoring the API for web notifications, and would like your feedback. We are working on getting permission to join the Web Notifications working group, but thought that while doing that I could try to get some general consensus from the WebKit community about these changes prior to proposing them to the WG.
The basic intents of the refactoring are to a) align the API with the design of recent APIs in the WebApps WG and elsewhere, and b) to simplify the API by removing unnecessary bits. With these changes I think we can put the API in a good place for future enhancements. ==== Here are the proposed changes: 1. Move the factory method to a constructor function. new WebKitNotification(title, body, [optional] iconURL) This is similar to the spec [NOTIF], except that the icon URL has been moved to the end as an optional argument. Notification platforms may choose not to load the URL for privacy reasons, and I think it should not be a required component for a text notification. 2. Remove HTML notifications. It has been removed from the spec, and we don't intend on ever supporting HTML notifications. I brought this issue up before; is there an update on this front from any other platforms? 3. Use static functions on the notification constructor for permissions checks. By moving them there, it allows us to remove window.webkitNotifications and the NotificationCenter class, cleaning up the API. 4. Adjust the permission functions. WebKitNotification.permissionLevel() --> String Similar to checkPermissions(), synchronous call. The name aligns with similar functionality in the DAP Feature Permissions spec [FEAT], but scoped specifically to Web Notifications. Returns one of three strings: "granted", "denied", and "default". This follows the current best practice from the WebApps WG where strings are being used instead of enums. WebKitNotification.requestPermission(callback) An asynchronous call, as it is currently. The callback specified includes one argument which represents the permission, similar to the return values in permissionLevel(). (Currently it is just a void callback.) If the user had already made a policy decision, then the callback is invoked immediately (with either "granted" or "denied"). Otherwise the UA may ask the user for permission, and the callback is invoked when the user makes a decision (cancelling the request does not invoke the callback). Any notifications posted in the meantime would be queued until then. Multiple calls to this function should just result in one visible request. 5. Remove replaceId. This could already be done by canceling a previous notification and posting a new one. The idea of replacing a notification with another one without alerting the user is a feature that we don't intend on supporting. 6. Improve show() behavior. Calling show() when the site has been denied permission should call onerror(). If no decision was made, then the notification should remain queued, and only until after the user has decided should onshow() or onerror() be called. I also think show() can only be used once. Subsequent invocations should call onerror(). 7. Remove ondisplay. The spec uses onshow instead. ==== More minor implementation details: 1. Rename NotificationPresenter to NotificationClient. This is just to make it follow the nomenclature of all page clients. 2. Simplify Notification and merge NotificationContents into it. I am unsure what the purpose of moving the data out into a separate class was, but it seems unnecessary. ==== If you got this far, thanks for reading. Any and all feedback welcome! Regards, Jon [FEAT] http://dev.w3.org/2009/dap/perms/FeaturePermissions.html [NOTIF] http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
