Re: Push API draft uploaded

Re "a particular type of Push service that it supports" this is intended to be generic so that new services (perhaps identified by unique URI schemes) can be covered under this.

That being said, WebSockets schemes clearly would imply that protocol, but http schemes could be more flexible. One of the goals is to define how the "serviceUrl" is conveyed to the user agent and Webapp. In the process of determining that URL, there could be other useful info that the server returns, eg the applicable bearer bindings or info that will help ensure events can be delivered to the correct Webapp (e.g. SMS source address, message fields/headers). If its possible to define a lightweight and generic/extensible Push service registration protocol, this would be a good place to invoke it. We defined such a protocol for OMA Push, and some of those ideas might be useful here. This is an area for further study.

If the Push server connection is setup to another domain then CORS would apply. But the checkRemotePermission method (at least as I understood it from the Mozilla proposal) would only test if there was a prior permission by the user, and would not need to invoke any network transactions to do so (though for some implementations this might be a feature).

I will try to develop these ideas in the draft (or at least outline the intent to), but I did not want to put too much into it at this time... As far as possible I am leaning to the simple (but clearly not as simple as the Mozilla proposal). Service lifecycle management, of which registration is a facet, can hopefully be layered above the API for the most part.

Thanks,
Bryan Sullivan

On May 24, 2012, at 9:33 AM, "Charles Pritchard" <chuck@jumis.com> wrote:

> On 5/24/2012 7:08 AM, SULLIVAN, BRYAN L wrote:
>> OK, I corrected the [NoInterfaceObject] (I hope), and referenced HTML5 for "resolving a URL".
>> 
>> The numeric readyState was borrowed from EventSource. I will look at the thread, but I think this is something that I will just align with the consensus in the group once determined. I don't have a strong opinion either way.
>> 
>> Latest version is athttp://dvcs.w3.org/hg/push/raw-file/default/index.html  
> 
> Does the following mean that "http/https" are interpreted as EventSource and ws/wss as WebSockets?
> Does checkRemotePermission trigger CORS checks for those protocols?
> 
> "If the url parameter is present and the user agent recognizes the url value as a particular type of Push service that it supports, the user agent must activate the service."
> 
> My read on that is yes and yes, but I wanted to double-check.
> 
> -Charles

Received on Thursday, 24 May 2012 15:25:08 UTC