Re: [Push API] Fine-grained unsubscription

On 4 April 2016 at 16:34, Marco Colli wrote: > 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"

Re: [Push API] How to detect acceptable Content-Encoding for each UA

On 4 March 2016 at 18:07, Tomoyuki SHIMIZU wrote: > 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

Re: Web Push API intended scope

On 16 January 2016 at 08:06, Ben Last wrote: > 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:

Re: Web Push API intended scope

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&g

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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}

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

[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

[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

[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

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); } }

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