Re: [Push API] Fine-grained unsubscription
On 4 April 2016 at 16:34, Marco Colliwrote: > A simple way to implement this would be to add an editPreferencesUrl option > to the pushManager.subscribe(). Then, when the user clicks the wheel to turn > off push notifications sees two options: "Turn off all notifications" and > "Manage push preferences on the website". When he clicks the latter is sent > to the editPreferencesUrl on the website. This is really something that you want to take up with browser vendors. In that regard, I can only tell you that developing UI around these features is very difficult.
Re: [Push API] How to detect acceptable Content-Encoding for each UA
On 4 March 2016 at 18:07, Tomoyuki SHIMIZUwrote: > On the other hand, it could be renamed according to encryption spec update > (e.g. changing from "aesgcm128" to "aesgcm"[2][3]). It might suggest each UA > might support different types or versions of Content-Encoding in the future. Firefox will support aesgcm128 for several releases once "aesgcm" is done (something I expect to happen in 48). By the time that Chrome supports the standard protocol (I think that's 51), both browsers will accept "aesgcm" as described in the pull request. Right now, it's more than just Content-Encoding people have to worry about, because Chrome supplies an endpoint that only talks the GCM protocol. I think that we can chalk that up to early adopter pains and rather begrudgingly suggest looking at the UA string.
Re: Web Push API intended scope
On 16 January 2016 at 08:06, Ben Lastwrote: > I don't recall this being stated as a design goal or implicit requirement, > though I may have missed it. What counts as infrequent in this context? Maybe it wasn't express, but implied. There are a few simple drivers for this: 1. Push messaging is intermediated and relatively slow and expensive; direct communication is always cheaper and faster 2. ...but only when you already have a connection; maintaining a long term connection from multiple clients is very expensive. Therefore, push is best used when you don't have a direct communication channel open to your site. Use direct connections when available, but let them close and use push when you aren't actively using them.
Re: Web Push API intended scope
Paul, just for you: https://github.com/w3c/push-api/issues/179 On 13 January 2016 at 19:17, Paul Banks <ba...@banksco.de> wrote: > Hi Martin, > > Thanks for the clarification. This makes sense to me. > > Perhaps I missed it - I'll read again closely but I wonder if that intent > could be expressed in those clear terms in the draft text? I don't recall > seeing "infrequent" messaging mentioned at all for example. > > Thanks again. > > Paul > > > >> On 13 Jan 2016, at 04:38, Martin Thomson <martin.thom...@gmail.com> wrote: >> >> Hi Paul, >> >> The Push API is intended for infrequent messages. If you have a page >> open to site, it might still be suitable to rely on push for messages >> that are infrequent or unpredictable. However, if you are actively >> communicating with your site, it is best to use more direct means of >> sending messages, such as HTTPS. Direct communications is both faster >> and more efficient if you are already actively talking to a server. >> >> The intent of the text you cite about building alternative delivery >> mechanisms, is intended to discourage application developers from >> building a long-running communications channel solely for the purpose >> of receiving low-rate, or low-probability messages. Many web >> applications do this today and it has a terrible effect on device >> battery life. >> >> --Martin >> >>> On 12 January 2016 at 09:08, Paul Banks <ba...@banksco.de> wrote: >>> Hi all, >>> >>> I came across the Web Push draft spec recently while researching the >>> current state of the art for pushing “real-time” updates to web >>> applications. >>> >>> I’ve read the draft spec as it stands and I’m excited about the >>> possibilities. >>> >>> But I’m a little unsure of the intended scope. >>> >>> Is the intention that this should be the primary mechanism for pushing >>> updates while app IS loaded in browser as well as a mechanism for showing >>> “offline” notifications when app is not open? >>> >>> For example, Chrome’s implementation appears to require a visual >>> notification be displayed per message (according to >>> https://developer.mozilla.org/en/docs/Web/API/Push_API). The Firefox >>> implementation according to the same page places some limit on updates that >>> can be received without showing a notification, although "The limit is >>> refreshed each time the site is visited”. >>> >>> I feel I’m trying to read between the lines about whether this proposal is >>> intended to be suitable for general purpose pushing even while app is >>> visible. >>> >>> I note that Facebook’s current implementation supplements their on-page >>> real-time transport which is still based on long-polling XHRs. >>> >>> But then section 7.4 >>> https://martinthomson.github.io/drafts/draft-thomson-webpush-http2.html#rfc.section.7.4 >>> talks about an intention to not make apps implement alternative delivery >>> mechanisms, although it’s not clear to me how that would even be possible >>> for the “offline” case which needs this browser support. That seems to >>> imply that it is intended for delivering messages to loaded application >>> tabs too which seems at odds with some of the language above. >>> >>> If it *is* intended to become the single transport for apps to receive push >>> updates even when loaded in tab, I have further questions. However before I >>> dive into deep examples, I wanted to check I was understanding the scope >>> and intended use of this proposal correctly. >>> >>> If anyone has thoughts to share or links to material I can read to find out >>> more than the proposal spec and github issues I’ve seen, I’d be very >>> grateful. >>> >>> Thanks for the work on this - it seems like a great opportunity to bring >>> web app interactivity back on par with native mobile apps without >>> reinventing the message transport each time! >>> >>> Paul >>>
Re: Web Push API intended scope
Hi Paul, The Push API is intended for infrequent messages. If you have a page open to site, it might still be suitable to rely on push for messages that are infrequent or unpredictable. However, if you are actively communicating with your site, it is best to use more direct means of sending messages, such as HTTPS. Direct communications is both faster and more efficient if you are already actively talking to a server. The intent of the text you cite about building alternative delivery mechanisms, is intended to discourage application developers from building a long-running communications channel solely for the purpose of receiving low-rate, or low-probability messages. Many web applications do this today and it has a terrible effect on device battery life. --Martin On 12 January 2016 at 09:08, Paul Bankswrote: > Hi all, > > I came across the Web Push draft spec recently while researching the current > state of the art for pushing “real-time” updates to web applications. > > I’ve read the draft spec as it stands and I’m excited about the possibilities. > > But I’m a little unsure of the intended scope. > > Is the intention that this should be the primary mechanism for pushing > updates while app IS loaded in browser as well as a mechanism for showing > “offline” notifications when app is not open? > > For example, Chrome’s implementation appears to require a visual notification > be displayed per message (according to > https://developer.mozilla.org/en/docs/Web/API/Push_API). The Firefox > implementation according to the same page places some limit on updates that > can be received without showing a notification, although "The limit is > refreshed each time the site is visited”. > > I feel I’m trying to read between the lines about whether this proposal is > intended to be suitable for general purpose pushing even while app is visible. > > I note that Facebook’s current implementation supplements their on-page > real-time transport which is still based on long-polling XHRs. > > But then section 7.4 > https://martinthomson.github.io/drafts/draft-thomson-webpush-http2.html#rfc.section.7.4 > talks about an intention to not make apps implement alternative delivery > mechanisms, although it’s not clear to me how that would even be possible for > the “offline” case which needs this browser support. That seems to imply that > it is intended for delivering messages to loaded application tabs too which > seems at odds with some of the language above. > > If it *is* intended to become the single transport for apps to receive push > updates even when loaded in tab, I have further questions. However before I > dive into deep examples, I wanted to check I was understanding the scope and > intended use of this proposal correctly. > > If anyone has thoughts to share or links to material I can read to find out > more than the proposal spec and github issues I’ve seen, I’d be very grateful. > > Thanks for the work on this - it seems like a great opportunity to bring web > app interactivity back on par with native mobile apps without reinventing the > message transport each time! > > Paul >
Re: [WebIDL] T[] migration
On 16 July 2015 at 09:36, Domenic Denicola d...@domenic.me wrote: - https://w3c.github.io/webrtc-pc/ Specifically: https://w3c.github.io/webrtc-pc/#rtctrackevent - should be OK https://github.com/w3c/webrtc-pc/issues/251
Re: CORS performance proposal
On 8 June 2015 at 21:30, Nottingham, Mark mnott...@akamai.com wrote: A header denoting site-wide metadata would work for this too, of course, if folks were comfortable with the security properties of doing that (as well as the potential response overhead). The security properties bother me a little. Alt-Svc is showing us that we can't just define a header field like that without some serious analysis.
Re: Permissions API vs local APIs
On 6 May 2015 at 11:07, Doug Turner do...@mozilla.com wrote: 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? Just to present an alternative... A decentralized permissions status API would be consistent with what we have today. That would recognize that individual APIs already own their individual permissions stories. Embrace that rather than fighting it. The permissions API could be changed to define an interface and model that each API could apply
Re: Exposing structured clone as an API?
On 23 April 2015 at 15:02, Ted Mielczarek t...@mozilla.com wrote: Has anyone ever proposed exposing the structured clone algorithm directly as an API? If you didn't just do so, I will :) 1. https://twitter.com/TedMielczarek/status/591315580277391360 Looking at your jsfiddle, here's a way to turn that into something useful. +Object.prototype.clone = Object.prototype.clone || function() { - function clone(x) { return new Promise(function (resolve, reject) { window.addEventListener('message', function(e) { resolve(e.data); }); +window.postMessage(this, *); -window.postMessage(x, *); }); } But are we are in the wrong place to have that discussion?
Re: Exposing structured clone as an API?
On 23 April 2015 at 15:34, Elliott Sprehn espr...@chromium.org wrote: Have you benchmarked this? I think you're better off just writing your own clone library. Not really the point of my mail. Of course you would be better writing a real clone. It could probably even be synchronous, though it removes this (or a less bad version, see Maceij's comments) as a polyfill option.
Re: Privileged context features and JavaScript
On 17 April 2015 at 08:16, Boris Zbarsky bzbar...@mit.edu wrote: If the API returns a Promise type, return a Promise rejected with a TypeError (??). Otherwise, the operation steps MUST fail in some way. Or some such. SecurityError perhaps. But I still like the idea of an IDL annotation like [SecureContext] that causes the API to disappear as though not implemented.
Re: PSA: publishing new WD of File API on April 21
On 15 April 2015 at 07:26, Arthur Barstow art.bars...@gmail.com wrote: * This spec is now using Github https://w3c.github.io/FileAPI/ That repo is actually https://github.com/w3c/FileAPI/. Since the most obvious github.io link is currently broken, would it make sense to move Overview.html to index.html? Does the name Overview.html hold special meaning?
Re: CORS performance proposal
On 21 February 2015 at 20:43, Anne van Kesteren ann...@annevk.nl wrote: High-byte of what? A URL is within ASCII range when it reaches the server. This is the first time I hear of this. Apparently, all sorts of muck floats around the Internet. When we did HTTP/2 we were forced to accept that header field values (URLs in particular) were a sequence of octets. Those are often interpreted as strings in various interesting ways. I wouldn't *completely* discount the potential for the conversions Jonas mentions here. A Java server might parse UTF-8 into the internal UTF-16 representation and then who knows what happens next.
Re: CORS performance proposal
On 20 February 2015 at 00:29, Anne van Kesteren ann...@annevk.nl wrote: Access-Control-Allow-Origin-Wide-Cache: [origin] This has some pretty implications for server deployments that host mutual distrustful applications. Now, these servers are already pretty well hosed from other directions, but I don't believe that there is any pre-existing case where a header field set in a request to /x could affect future requests to /y. An alternative would be to use /.well-known for site wide policies.
Re: CORS performance
On 18 February 2015 at 06:31, Brad Hill hillb...@gmail.com wrote: Some of the things that argue against /.well-known are: 1) Added latency of fetching the resource. It's not available everywhere yet, but you could push it, based on the below. 2) Clients hammering servers for non-existent /.well-known resources (the favicon issue) You could avoid that by Link:-ing to the /.well-known and only hitting it if the link appears.
Re: CORS performance proposal
On 20 February 2015 at 11:39, Bjoern Hoehrmann derhoe...@gmx.net wrote: The proposal is to use `OPTIONS * HTTP/1.1` not `OPTIONS /x HTTP/1.1`. I missed that. In which case I'd point out that `OPTIONS *` is very poorly supported. Some people (myself included) want it to die a flaming death.
Re: Push API: not a friend of SPDY
On 27 October 2014 08:42, rekt...@voodoowarez.com wrote: Anyone who wants to implement a transport can frame it as they please. Building a Push that throws away this information when the message is an HTTP message is something that the lightcone of humanity will hate you for for as long as it holds together. You really really really can not skimp on this because you happen to want other circumstances: if you are building a Push spec for the web, it needs to be able to recieve web-like requsts. That's a pretty strong assertion. Can you provide any justification for that? Any metadata you might want to carry can always be placed in a payload after all.
Re: Push API change for permissions UX
On 24 October 2014 09:09, John Mellor joh...@google.com wrote: For background sync[1], such a throttling approach would be ideal, as there is no expectation of timeliness. But push is different: users can come to depend on timely delivery of push notifications, and sufficiently heavy-handed throttling would introduce unreliability/inconsistency - especially if the goal is to mitigate geoip tracking, since only a handful of push messages might be enough to locate e.g. your home and work. Isn't that a perfect disincentive? Apps learn that abusing push leads to a terrible user experience. And we can mitigate that by using the prioritization mechanisms that push provides, allowing apps to identify less important messages that can be dropped first. The rules need not be complex, for example: one high priority message per user interaction or per hour (whichever is shorter), 3 medium priority messages in the same time, and 5 low priority messages; more may be permitted but not guaranteed. I don't share your concern with respect to geoip tracking; or at least I don't give it the same amount of weight you seem to. If you permit an application to run in the background, then this is one of the many things the app will be able to do. The same sort of tracking is enabled by having tabs left open. app to just always show a notification of its choice (which will at least be slightly useful) I can think of nothing worse than something that forces the creation of a notification. Notifications consume user attention, of which there is (qualitatively) far less of than battery Joules or network bytes.
Re: Push API change for permissions UX
On 23 October 2014 04:10, John Mellor joh...@google.com wrote: Can you elaborate? This would attach no penalty to developers who don't opt in (at the one time cost of an additional permission prompt); and as I explained above, developers who do opt in would indeed be incentivized to always show user-visible UI. Are you concerned that this is not the right thing to be incentivising? Yes, it increases the cost in terms of battery consumption and user annoyance for push messages. Both of which we strive to minimize. You might claim that the app needs to take responsibility for this, but I'm less certain. It means that important features that provide these measures (do not disturb, more contextual event filtering) are not available to applications by default. I'd like to find better ways of dealing with this problem. This approach seems like more of a cop-out to me. I'm seriously jet-lagged, so only two ideas spring to mind, I'm sure you can find some more if you set your mind to it: Usage budgets might be applied to various resources, after which a SW is activated less often. Or good accounting and reporting (see various activity monitors on different operating systems that account for all sorts of resource usage, or you could generate simple notifications like: this app is burning your battery/network, turn it off?)
Re: Push API - PushRegistration and lifetime
On 22 October 2014 22:19, Shijun Sun shij...@microsoft.com wrote: Thanks Martin. It'd be very helpful if PushRegistration can have a read-only attribute for ExpirationTime or something like that. Webapps can be more proactive if the ExpirationTime is set. I was thinking that this was a protocol concern primarily and that the UA would be the best place to be proactive. As Costin points out, if we get individual apps being proactive, they won't know about whether the radio is on, and they won't coordinate properly. I think that I'd prefer to have the UA consume any expiration information and not expose it in the API.
Re: Push API and Service Workers
On 19 October 2014 19:18, Shijun Sun shij...@microsoft.com wrote: It'd be great if the Push API spec allows the web developers to have flexibility to leverage the generic actions, or rely on a service worker, or maybe doing both. I imagine that we will permit the use of whatever a service worker has access to. Some of that is going to require prior arrangement (i.e., consent prompts might be required to enable a full screen alert, though maybe toasts).
Re: Push API and Service Workers
On 16 October 2014 08:55, Shijun Sun shij...@microsoft.com wrote: Re #2, it'd be great if some folks could comment on the scheduling and latency question. There are number of variations on how this all works out. And multiple sources of latency. A mobile device in a low power state follows a process that is approximately: 1. network pages the device 2. device establishes a network context (considerable delay in some cases here...I've heard 2s isn't unusual...gah!) 3. network delivers the push message 4. OS delivers to push service on device (some services may initiate a user notification at this point based on the message contents, but it isn't a default mode) 5. OS awakens a push handler (a subset of the application) 6. push handler runs code to determine what to do, which may be Steps 5 and 6 are entirely analogous to the service worker case. The problem that Anne highlighted is the risk that the service worker requires download and installation when the event arrives. I think that we should be recommending that push messages are run from a previously installed (and cached) service worker. Latency really matters here. We could, of course, get fancy and require update of the SW if it has expired from cache, or maybe allow update for messages that are marked low priority, but I'd consider that to be a second-order optimization.
Re: Push API and Service Workers
On 16 October 2014 11:17, John Mellor joh...@google.com wrote: In our prototype on Android, it takes less than a second (not yet optimized) to wake up Chrome from a cold start and handle the event in a Service Worker (the demo writes to IndexedDB and shows a notification), versus less than 100ms to handle the event when Chrome and the SW are already running. Since push messages aren't usually triggered by a user action (like a button click), but instead by some external event, these latencies are already likely to be imperceptible to users. If the push message is being used to deliver a call notification, that sort of delay will definitely be noticed. And I'm assuming that you've tested on a high end Nexus or something like that. Add the latencies involved in waking an idle device and that turns into a very long post-dial delay. People abandon calls for that sort of delay. Not saying that you are doing it wrong or anything, but just trying to set the right expectations.
Re: Push API and Service Workers
On 15 October 2014 14:58, Domenic Denicola dome...@domenicdenicola.com wrote: So from my perspective, implementing the push API without service workers would be pretty pointless, as it would give no new capabilities. That's not strictly true. If I sit (as I do) with a tab open to gmail for a very long time, then it is of some advantage to me (and my network usage) to use something like push rather than websockets (or even server sent events). Besides, server sent events might be roughly equivalent, but they are horribly kludgy and suffer from robustness issues.
Re: Service worker popup (rich notification)
On 2 October 2014 05:48, John Mellor joh...@google.com wrote: So I guess this is something we'll want to support eventually, but it's blocked on coming up with clear UI for safely granting and revoking permission to show popups from the background. Doesn't this already exist, at least in some form? Gecko already has permissions management functions for Show Notifications.
Re: [Webpush] IETF proposes new Web-Based Push Notifications Working Group
If you would prefer that the IETF wg charter refer to something else, please let me know promptly. A small correction is still possible, but the window is closing. On Sep 26, 2014 1:47 PM, Arthur Barstow art.bars...@gmail.com wrote: On 9/24/14 1:21 PM, Michael van Ouwerkerk wrote: The linked working draft is now more than a year old. The latest editor's draft has some inconsistencies while we transition to a service worker based system, but it's much closer to the current discussions: https://w3c.github.io/push-api/ Thanks for pointing this out Mike. Since the ED uses respec, it's trivial to prepare a new WD for publication. Bryan, Eduardo - given IETF directly refers to the TR version of Push API, I recommend we publish a new WD for Push API? [1] gets us pretty close and I can help. OK? -Thanks, AB [1] https://w3c.github.io/push-api/?specStatus=WD;publishDate=2014-10-02; previousPublishDate=2013-08-15
Re: [push-api] Object values in push messages
On 13 May 2014 02:47, Anne van Kesteren ann...@annevk.nl wrote: Can't we mirror WebSocket? That seems like it would be quite a bit simpler than full-blown HTTP messages. Almost, though we'd need that single bit of metadata that thewebsocketprotocol uses to signal text/binary. I think that XHR is a better fit, assuming that MIME makes sense architecturally.
Re: [push-api] Identifying registrations
On 13 May 2014 06:39, Michael van Ouwerkerk mvanouwerk...@google.com wrote: Martin, in Chrome we use registrationId and endpoint for distinct purposes. The endpoint is the push server url to which the app server posts new messages. The registrationId identifies the correct {device, user, page} to which the message will be sent. I think that the spec needs to be a lot clearer on the purpose (and usage) of each of these things. Personally, I think that a better model would be this: interface PushManager { PromisePushRegistration register(); PromisesequencePushRegistration registrations(); }; interface PushRegistration { Promise unregister(); attribute DOMString id; attribute DOMString endpoint; }; interface PushMessage { attribute PushRegistration registration; attribute ?? data; } Yes, aside from moving unregister, it's just names, but sometimes names are important. The reason behind moving unregister being that 'id' is only present for bookkeeping purposes, and many apps won't have to use it. That said, looking at this, I am sorely tempted to suggest adding EventTarget to PushRegistration and use events. Any reason that wouldn't be appropriate? p.s., I assume that the mess in the editor's draft regarding PushManager is due to a Respec.js issue around the use of promises.
Re: [push-api] Identifying registrations
On 13 May 2014 10:24, Michael van Ouwerkerk mvanouwerk...@google.com wrote: Hi Martin, note that the latest proposal is to have only a single registration at a time: http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0223.html Oh well, that's a little unfortunate. It's logical of course. Applications can perform routing on their own.
[push-api] Version information in push API
The push-api currently stipulates a method whereby applications can learn of missed messages. This uses a number that increases with every push message (version). This places some constraints on the push server implementation that are largely unnecessary when generic data transport is supported by the API. I think that removing version would simplify server implementation. Doug T also mentioned that there was an event that is fired when messages might have been missed, presumably relying on the version number to detect gaps. I don't see this in the editor's draft, so maybe this was only something in the mozilla implementation. The drawback of making this simplification is that applications will have to detect gaps or duplicates themselves. If we consider the standard comsec adversary model, in which the push server is not trusted, this is something that application should be doing for itself anyway.
[push-api] Object values in push messages
The current editors draft of the push API includes an `Object` in the PushMessage class. This assumes a great deal about the nature of the contents of pushed messages. I think that arbitrary data is more appropriate for this channel. To that end, I propose that the API be made congruent with the XmlHTTPRequest API (or whatever folks who are working on that might wish XHR looked like) so that pushed messages can contain MIME bodies. I think that this offers applications more flexibility. For instance, there are limitations on what can be pushed efficiently, and an application that aims to maximize the value of a push might want to push a binary blob.
[push-api] Identifying registrations
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: Progress on Push API
On 1 May 2014 16:55, Jonas Sicking jo...@sicking.cc wrote: function registrationHandler() { navigator.push.register().then((endpoint) = { sendBackToAppServer(endpoint); navigator.push.registrationNeeded.then(registrationHandler); } } navigator.push.registrationNeeded.then(registrationHandler); If it's going to happen over and over, why not an event? function register() { navigator.push.register().then(endpoint = sendToAppServer(endpoint)); } navigator.push.onderegister = e = register; Of course, you would have to set some expectations around how quickly the browser is required to detect this error. 30 minutes is a pretty common liveness interval for these things, which might not meet the usual timeliness expectations for applications.
Re: Progress on Push API
On 1 May 2014 17:31, Jonas Sicking jo...@sicking.cc wrote: If it's going to happen over and over, why not an event? function register() { navigator.push.register().then(endpoint = sendToAppServer(endpoint)); } navigator.push.onderegister = e = register; For two reasons: * If the page does some initialization asynchronously then it might miss that the deregister event fires. I.e. it is very easy to accidentally register the onderegister event handler too late. * It would require that we for each page that the user visits check if that page has a registration, and if that registration has been lost by the server. We only want to do this on pages that care about push registration and is actually going to make a registration if needed. Not for every page the user visits. Fair points, but with a an event coupled to a state (attribute boolean registered), this can be avoided. I guess that the point of your second proposal at least is that it sort of rolls all that into the one package. I think that I prefer the registration needed callback approach, even though it seems to be a little surprising in the sense that it shares many characteristics with events. Maybe a onregistrationneeded event would be a closer fit.