Re: Permissions API vs local APIs
On May 6, 2015, at 11:00 AM, Jonas Sicking jo...@sicking.cc wrote: FWIW, the permission API as it currently stands is pretty trivial to implement. So I don't see a reason to delay until 2017 or even Q3 2015. If the spec is ready to go (what’s anne’s worry), then lets implement it and remove the stuff from PushAPI. Marcos|Mounir, do you two have any thoughts on this?
Re: Permissions API vs local APIs
The way I would look at this is based on timeframe — if we’re not implementing the Permissions API until 2017 or something, i’d just leave the functionality in the PushAPI spec. If the Permission API is right around the corner, I would remove it form the PushAPI spec. Do any other APIs have a permission check function in their interface? Geo doesn’t (which shares a similar permission model). On May 6, 2015, at 8:39 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 6, 2015 at 5:33 PM, Jonas Sicking jo...@sicking.cc wrote: I think Mozilla would be fine with taking the permission API as a dependency and implement that at the same time. Implementing the permission API should be fairly trivial for us. But we should verify this with the people actually working on the push API. On Wed, May 6, 2015 at 10:59 AM, Michael van Ouwerkerk mvanouwerk...@google.com wrote: Yes, we wanted to ensure this is in the Push API because that seems to have more implementation momentum from browser vendors than the Permissions API. We didn't want developers to do hacky things in the meantime. I agree that once the Permissions API has critical mass, that should be the single place for checking permissions. Martin, Doug? -- https://annevankesteren.nl/
Re: [push] protocol drafts
The websocket version documents what we did for Mozilla and TEF's push system. I also support Martin's draft as a base. On Tue, May 13, 2014 at 8:44 AM, Peter Beverloo bever...@google.com wrote: While I haven't finished reviewing it yet, the removal of the dependency on Web Sockets is something we're strongly in favor of. Choosing which protocol the IETF group is going to pursue is a decision to be made there, at least until the Web Push API gains a formal dependency on it. For the record, I support taking Martin's draft as a base. Thanks, Peter On Tue, May 13, 2014 at 5:37 PM, Doug Turner do...@mozilla.com wrote: My draft is basically what we do today. Martin's draft leverages http2 and is much cleaner/simpler. I am not sure which we are putting our money on yet, but I suspect it will be Martin's. On Tue, May 13, 2014 at 4:41 AM, Arthur Barstow art.bars...@gmail.com wrote: Hi Martin, Doug, I noticed there are two drafts related to push protocol: http://tools.ietf.org/html/draft-thomson-webpush-http2-00 http://dougt.github.io/webpush-protocol/draft-turner-webpush.html What are the plans and expectations for these specs (f.ex. do they address different use case and thus are independent; are they to be merged; is one to replaced/usurped by the other; survival of the fittest; standardization plans; ...)? -Thanks, ArtB
Re: [push-api] Identifying registrations
The thinking behind this would be that people might use the
pushEndpoint as the 'type' of push notification service you are
talking to (gcm, mozilla, samsung, apple, etc) and the
pushRegistrationID as the identifier. Doing it this way avoids having
to parse URLs... sorta.
On Mon, May 12, 2014 at 4:08 PM, Martin Thomson
martin.thom...@gmail.com wrote:
The push API currently identifies a registration with a tuple:
interface PushRegistration {
readonlyattribute DOMString pushEndpoint;
readonlyattribute DOMString pushRegistrationId;
};
It looks like both are used by the push server. Local methods seem to
rely on the pushRegistrationId; the remote application server uses the
pushEndpoint, though details are not currently specified [1].
In my experience, the pushEndpoint is a sufficiently unique
identifier. Contingent on some conclusions on the protocol side, this
could be defined as a URL and used as an identifier. That single
identifier should suffice.
--Martin
p.s., the register() method on PushManager should be updated to return
PromisePushRegistration or PromiseDOMString as appropriate.
[1] see webp...@ietf.org and related effort there
Re: Thoughts on WebNotification
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. I think it's reasonable. On the other hand, do you think the Geo spec needs changing to allow this? As I read it, I think it already allows it. Clearly no. Just wanted to give you a heads up.
Re: Thoughts on WebNotification
On Jun 25, 2010, at 8:39 AM, John Gregg wrote: On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner doug.tur...@gmail.com wrote: Hey Drew, I think this is too vague, as it's sounds like a user agent could *not* ignore markup in the string, and still be compliant with the spec. I think we need to be very explicit that the string *must* be treated as plain text. So if I pass in gt;bfoo/b as the body parameter to createNotification(), the resulting notification must display the string gt;bfoo/b, without stripping or converting any of the substrings that might look like HTML entities. Yup. we should tighten up the language. i think we are on the same page here. It's actually more complicated given the various platform behavior. While Growl doesn't interpret markup, NotifyOSD on linux does allow some markup in its notifications (lt; shows , for example) [1, section 5]. So it's not sufficient to just pass the string directly, it has to be escaped in order to present the exact text provided. So perhaps, the user agent must display the string as plain text, without interpreting markup; if using a notification platform which does interpret markup, the user agent should modify the string so that any markup is shown rather than interpreted. [1] https://wiki.ubuntu.com/NotificationDevelopmentGuidelines From an implementation pov, this text sorta scares me. Figuring out which notification platform interpret which character sequences sounds hard. And these system are not static and must be reevaluated constantly. I think it might make it a bunch easier to simply say that UA should strip out any escape sequences or html tags. What do you think? Doug
Re: Thoughts on WebNotification
I'm concerned that it would make it impossible to display a certain category of strings in notifications. Suppose we're both web devs, I'm chatting with you and want to share with you a snippet of code; will the chat notification be blank? I agree with the problem of depending on the providers, but if we do want to be able to specify dependable output for input (my interpretation of this discussion), I think we have to make some sort of effort there. make sense. i agree with you.
Thoughts on WebNotification
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) {});
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.
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.
I hope that this is helpful,
Doug Turner
Mozilla Corp
[1] http://dougt.org/wordpress/2010/06/desktop-notifications/
[2] http://dev.w3.org/2006/webapi/WebNotifications/publish/
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.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
Re: Thoughts on WebNotification
Hey Drew, I think this is too vague, as it's sounds like a user agent could *not* ignore markup in the string, and still be compliant with the spec. I think we need to be very explicit that the string *must* be treated as plain text. So if I pass in gt;bfoo/b as the body parameter to createNotification(), the resulting notification must display the string gt;bfoo/b, without stripping or converting any of the substrings that might look like HTML entities. Yup. we should tighten up the language. i think we are on the same page here. 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. I'm not certain what moving WebNotifications to version 2 would mean, especially since as specified, user agents already are free to leave createWebNotification() undefined. Can you please clarify what you think, in practice, having createWebNotification() moved to version 2 would accomplish? Since compliant user agents are already free to *not* implement this API, it sounds like your only goal could be to discourage other user agents from implementing the createWebNotification() API, and I'm not at all convinced that's either appropriate or feasible. My thinking, right or wrong, was that it might be nice to say that most UAs will support version v.1 (that doesn't include things like webnotifications). And in v.2 is the things that some UAs aren't willing to implement at the present time. In practice, though, it really doesn't matter. Doug
Re: Orientation event in Firefox
Hey Marcin, OrientationChangeEvent (as much as any name) sound fine, but I do not see what values you are passing into the event handler? The defition was not in [1] or [2] listed in your post, or in the mediafeatures.html attachment. What am I missing? Doug Turner On Aug 24, 2009, at 1:41 AM, Marcin Hanclik wrote: Hi Doug, What do you think about the proposal in [1]? Some discussion is needed on WebApps for this topic to move forward. Thanks, Marcin [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0764.html Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org ] On Behalf Of Doug Turner Sent: Monday, August 24, 2009 5:40 AM To: wha...@whatwg.org; public-device-a...@w3.org Subject: Orientation event in Firefox I posted some thoughts and a strawman for orientation in Firefox: http://dougt.org/wordpress/2009/08/orientation/ Regards, Doug Turner Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
