Le mode "push" en web s'obtient actuellement via WebSocket ou Comet.
Et surtout avec Server Sent Events, qui est vraiment fait pour ça et qui répond très bien à ce besoin.
Mais que ce soit du Server Sent Events, du WebSocket ou du Comet, le « push » se fait d'un serveur vers un onglet d'un navigateur. Cela veut dire que si j'ouvre 10 onglets avec la tribune de LinuxFr.org dans mon Firefox, je vais ouvrir 10 connexions vers le serveur qui vont toutes recevoir les mêmes données. C'est dommage de ne pas mutualiser ces ressources. La push API permet cela en ouvrant un canal de communication entre le navigateur et un serveur particulier, le serveur de push. Les applications pourront pusher des messages à ce serveur qui les transférera au navigateur, qui lui-même fera en sorte de les délivrer aux bons onglets.
Dans l'autre sens, si je ferme tous mes onglets, je ne pourrais plus recevoir d'événements. Un des cas d'usage de la push API est justement de pouvoir lancer une webapp quand un message arrive qui lui était destiné. Par exemple, si j'ai utilisé une webapp de météo pour configurer des alertes, je pourrais être prévenu qu'une tempête se prépare même si j'ai fermé l'onglet de cette webapp.
Il y a d'autres cas d'usage qui me laisse plus perplexe. Si j'ouvre mon webmail dans 2 navigateurs, alors je pourrais profiter de la même connexion (au sens TCP) pour recevoir des notifications pour les deux. Je suis d'autant plus perplexe que le choix de la méthode pour se connecter au serveur de push (Server Sent Events, SIP, SMS, etc.) est laissé au choix du navigateur.
Enfin, je doute que cette API soit rapidement utilisable : elle pose pas mal de questions de sécurité et vie privée. En particulier, je ne pense pas que ça puisse fonctionner sans la Web Crypto API, qui n'est, à ma connaissance, implémentée par aucun navigateur.
[^] # Re: Pousse-toi de là
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #44. Évalué à 9.
Et surtout avec Server Sent Events, qui est vraiment fait pour ça et qui répond très bien à ce besoin.
Mais que ce soit du Server Sent Events, du WebSocket ou du Comet, le « push » se fait d'un serveur vers un onglet d'un navigateur. Cela veut dire que si j'ouvre 10 onglets avec la tribune de LinuxFr.org dans mon Firefox, je vais ouvrir 10 connexions vers le serveur qui vont toutes recevoir les mêmes données. C'est dommage de ne pas mutualiser ces ressources. La push API permet cela en ouvrant un canal de communication entre le navigateur et un serveur particulier, le serveur de push. Les applications pourront pusher des messages à ce serveur qui les transférera au navigateur, qui lui-même fera en sorte de les délivrer aux bons onglets.
Dans l'autre sens, si je ferme tous mes onglets, je ne pourrais plus recevoir d'événements. Un des cas d'usage de la push API est justement de pouvoir lancer une webapp quand un message arrive qui lui était destiné. Par exemple, si j'ai utilisé une webapp de météo pour configurer des alertes, je pourrais être prévenu qu'une tempête se prépare même si j'ai fermé l'onglet de cette webapp.
Il y a d'autres cas d'usage qui me laisse plus perplexe. Si j'ouvre mon webmail dans 2 navigateurs, alors je pourrais profiter de la même connexion (au sens TCP) pour recevoir des notifications pour les deux. Je suis d'autant plus perplexe que le choix de la méthode pour se connecter au serveur de push (Server Sent Events, SIP, SMS, etc.) est laissé au choix du navigateur.
Enfin, je doute que cette API soit rapidement utilisable : elle pose pas mal de questions de sécurité et vie privée. En particulier, je ne pense pas que ça puisse fonctionner sans la Web Crypto API, qui n'est, à ma connaissance, implémentée par aucun navigateur.