Re: [Push API] Fine-grained unsubscription

2016-04-05 Thread Martin Thomson
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" 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

2016-03-04 Thread Martin Thomson
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 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

2016-01-15 Thread Martin Thomson
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:

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

2016-01-13 Thread Martin Thomson
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

2016-01-12 Thread Martin Thomson
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  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: [WebIDL] T[] migration

2015-07-16 Thread Martin Thomson
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

2015-06-08 Thread Martin Thomson
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

2015-05-06 Thread Martin Thomson
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?

2015-04-23 Thread Martin Thomson
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?

2015-04-23 Thread Martin Thomson
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

2015-04-17 Thread Martin Thomson
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

2015-04-15 Thread Martin Thomson
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

2015-02-21 Thread Martin Thomson
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

2015-02-19 Thread Martin Thomson
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

2015-02-19 Thread Martin Thomson
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

2015-02-19 Thread Martin Thomson
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

2014-10-27 Thread Martin Thomson
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

2014-10-24 Thread Martin Thomson
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

2014-10-23 Thread Martin Thomson
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

2014-10-23 Thread Martin Thomson
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

2014-10-20 Thread Martin Thomson
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

2014-10-16 Thread Martin Thomson
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

2014-10-16 Thread Martin Thomson
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

2014-10-15 Thread Martin Thomson
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)

2014-10-02 Thread Martin Thomson
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

2014-09-26 Thread Martin Thomson
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

2014-05-13 Thread Martin Thomson
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

2014-05-13 Thread Martin Thomson
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

2014-05-13 Thread Martin Thomson
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

2014-05-12 Thread Martin Thomson
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

2014-05-12 Thread Martin Thomson
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

2014-05-12 Thread Martin Thomson
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

2014-05-01 Thread Martin Thomson
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

2014-05-01 Thread Martin Thomson
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.