RE: Push API draft uploaded

Greetings Bryan,

First thanks for digging into it, here are some comments I have mostly stuff I feel is missing from the spec (and I guess some points may be open to discussion on wether they fall in the scope of this spec or not) : 

- Positioning towards the eventSource API. As far as developer is concerned both these specs seem to accomplish mostly the same thing. I feel we should add some clarification on when one or the other should be used.

- Some callflows (I guess this is due to the early stage of the spec tho), from what I get the UA creates a pushservice indicating the URL of a selected push "proxy" and gets a URL where the webapp can send messages to that it then needs to communicate to the service server to actually be able to start getting messages.

- Specs for the proxy, so far only the user agent side is defined and the exchanges between UA and proxy seem to remain fuzzy, same goes on the exchanges between proxy and web server.

- Bearer switching, one of the points to introduce the spec was to be able to switch bearers for eventsources to allow battery saving on mobile devices. But there seems to be nothing about it in the spec. Are we letting the bearer switch to be done by the use of a different push service for lets say IP and SMS Push ? If so how is the change handled and what events can the app developer rely on to decide to switch ?

- SLAs, default services, multiple services... Again from a first look every application seems to be able to select its own push service proxy, as it is defined I feel the application developer has to publish his own push proxy in order to use the API (that's why I feel we should have a must have for a default proxy somewhere (could actually just be some kind of fallback to eventsource). Also every application can have its own proxy, if those proxies are some of those proxies are "public" (ie accept notification support from other applications) it would be interesting to know that and also to know if some of those proxies offer some guarantees as far as QoS is concerned, and thus have some form of mechanism to discover registered proxys within the browser (doubt the intent mechanism is ideal for this however) and criterias to select which one my application can use.

Cheers,

Arnaud Braud

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Received on Monday, 11 June 2012 21:41:17 UTC