Re: Thoughts on WebNotification

Thank you for your quick response!

On Jun 24, 2010, at 11:48 AM, John Gregg wrote:

> On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner <doug.turner@gmail.com> wrote:
> I have been thinking a bit on Desktop Notifications [1].  After reviewing the Web Notification specification [2], I would like to propose the following changes:
> 
> 
> 1) Factor out the permission api into a new interface and/or spec.  The ability to test for a permission without bring up a UI would improve the UX of device access.  I could imagine implementing this feature for use with Geolocation as well as notifications.  For example:
> 
> interface Permissions {
> 
> // permission values
> const unsigned long PERMISSION_ALLOWED = 0;
> const unsigned long PERMISSION_UNKNOWN = 1;
> const unsigned long PERMISSION_DENIED  = 2;
> 
> void checkPermission(in DOMString type, in Function callback);
> 
> }
> 
> Then we could do something like:
> 
> navigator.permissions.checkPermission("desktop-notification", function(value) {});
> 
> or
> 
> navigator.permissions.checkPermission("geolocation", function(value) {});
> 
> 
> I like this idea, I think it's definitely preferable to a one-off permission system just for notifications. 
> 
> Your proposal doesn't have a way to explicitly request permission.  Would you be willing to add that, with the recommendation that it only take place on a user gesture?  I don't think this eliminates the ability to implement request-on-first-use, if that's what Mozilla prefers, but I also still think there is benefit to allowing permissions to be obtained separately from invoking the API in question.

so, checkPermission and requestPermission.  I am happy with that......

and....

if really want to get crazy, we could do something like:

navigator.permissions.requestPermission("geolocation,desktop-notification",...).

This would allow a site to request multiple permissions in one go.... up to the implementation if this is supported (i'd argue), and up to the implementation on how best to handle these requests.


> The bigger question is, are other features interested?  Would the Geolocation spec consider using something like this for permissions?

cc'ing Andrei Popescu - the editor of the Geolocation spec.  Not sure how to formally answer your question.  However, if the permission api above was implemented, I think it naturally follows that "geolocation" would be one of the known strings.

> 2) Add language to the spec to indicate that the DOMStrings used |createNotification| are not to include any mark up.  Basically, implementations are going to hand off notifications to system-level services.  For example, on the Mac, GROWL does not handle any mark up... their API just takes plain strings.  I'd like to see the API reflect this reality.  Something like "the |title| and |body| arguments are to be treated as plain text"... or some such language.
> 
> 
> Although the group isn't chartered to deliver the spec forward, FWIW I agree with this suggestion (it was always the intent) and have made this language explicit in the editor's draft.

cool beans.


> 3) Move Web notifications to a version 2 of the specification.  For the most basic use cases, this API isn't required and a web developer could use the more base API to simulate this.  Furthermore, as I mentioned above, many system-level notification services know nothing about rendering html.
>  
> Though I think web content still makes sense for notifications coming from a web browser, and would want to publish an API which drives things in that direction, I think this is reasonable if it will encourage greater implementation of the basic API.  As long as the text+icon API we use doesn't cut off that avenue, and I think what we have now meets that.

Make it optional allows us to have a spec that interoperates.  I am not sure that Mozilla (or I) would want to implement this part of the specification.  My goal is for tight system level integration and I do not believe that web notifications helps on that.

Again, thank you for your thoughts,

Doug Turner

Received on Thursday, 24 June 2010 19:01:10 UTC