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.tur...@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
