Mozilla veut des notifications en push pour les applications HTML5

Je ne suis pas sûr d'avoir bien compris : si l'utilisateur (ou plutôt l'application cliente) doit aller consulter une url, alors ce n'est pas du push, si ?
Pour moi avec du push c'est le serveur qui initie l'envoi des notifs au client, et pas le client qui vient les chercher. Corrigez moi si je me suis planté.

En fait l'utilisateur ne consulte pas lui-même l'URL. C'est son système d'exploitation (par exemple Boot To Gecko) ou son navigateur (Firefox) qui le fait et traduit ce qui s'y trouve sous forme applicative.

Guillaume, le 06/02/2012 - 12:41

En fait l'utilisateur ne consulte pas lui-même l'URL. C'est son système d'exploitation (par exemple Boot To Gecko) ou son navigateur (Firefox) qui le fait et traduit ce qui s'y trouve sous forme applicative.

Vi, mais je ne suis pas sûr que ça soit du "vrai" push, à moins qu'ils veuillent utiliser des WebSockets, mais si j'ai bien compris ton explication, ça ne semble pas être le cas.
Comme l'a dit TuXiC69, le push est initié par le serveur. Là, il s'agirait du client qui irait régulièrement vérifier si le serveur lui propose des notifications. Alors que du vrai push, ce serait le serveur qui notifierait directement le client (sans que celui-ci ait besoin de faire de requête).
Je ne sais pas exactement comment fonctionnent les applications natives sur les smartphones, mais je ne suis pas sûr que ce soit du vrai push non plus.

sur les systèmes fermés comme iOS ou Android.

Android, un système "fermé comme iOS" alors qu'il s'agit d'un logiciel libre ? Gné ?

Juste un commentaire inutile en passant : la capture d'écran du futur Boot to gecko montre que le système est moche à la limite du supportable.
Une marque de fabrique ?

@Milord : exactement ce que je voulais dire. Je rajoute un petit lien https://fr.wikipedia...iki/Server_push

Pour les applications natives, aucune idée de comment c'est fait actuellement. Mais sur de la 3G ça me semble quand même intéressant d'avoir un vrai push, histoire de limiter le nombre de connexions nécessaires.

Et si ce n'est pas du vrai push alors ça me semble peu intéressant, ça se fait déjà très bien avec un peu d'Ajax

TuXiC69, le 06/02/2012 - 13:42

@Milord : exactement ce que je voulais dire. Je rajoute un petit lien https://fr.wikipedia...iki/Server_push

Pour les applications natives, aucune idée de comment c'est fait actuellement. Mais sur de la 3G ça me semble quand même intéressant d'avoir un vrai push, histoire de limiter le nombre de connexions nécessaires.

Et si ce n'est pas du vrai push alors ça me semble peu intéressant, ça se fait déjà très bien avec un peu d'Ajax

Ben c'est intéressant dans le sens où l'application cliente (le navigateur, à priori), serait capable de créer des notifications natives. Ca, tu ne peux pas le faire en ajax.
Mais sur le push en lui même, oui, ça n'a pas vraiment d'intérêt.

Android fermé ?

@Milord @TuXi69: et encore, le lien sur Wiki mentionne:
"Plusieurs méthodes permettent d'aboutir à un push serveur, la plus commune étant d'empêcher le serveur de clore la transaction. La connexion client-serveur reste ainsi ouverte, ce qui permet de mettre à jour instantanément les données chez les clients liés et évite de créer des queues parfois coûteuses du côté serveur."

Donc ca impose de garder la com ouverte, donc c'est aussi inadapté pour un appareil mobile si on ne veut pas bouffer son forfait et sa batterie.

De mon point de vue, le vrai push en HTTP n'est pas possible: le vrai push doit être implémenté en bas niveau dans le système, à la manière de la Push Registry en J2ME: le système est en attente de notification, en sommeil, il ne consomme rien et il se réveille sur une notif bas niveau (comme les SMS par exemple).

Le reste n'est que de la bricole. Même les apps soit-disant "push" comme gmail ou les clients Imaps font du polling de temps en temps à la place du push (qd le réseau s'active, qd l'utilisateur sort de la veille etc...).

La Fondation Mozilla, qui édite le navigateur Firefox et travaille sur son système d'exploitation mobile Boot To Gecko

Tiens, justement je me disais... On n'a pas assez d'OS pour mobile... Pourquoi Firefox et Opera ne pourraient pas en sortir un ou deux de plus ?

Je propose que Numerama sorte également son OS pour téléphone mobile

zig, le 06/02/2012 - 14:19

La Fondation Mozilla, qui édite le navigateur Firefox et travaille sur son système d'exploitation mobile Boot To Gecko

Tiens, justement je me disais... On n'a pas assez d'OS pour mobile... Pourquoi Firefox et Opera ne pourraient pas en sortir un ou deux de plus ?

Je propose que Numerama sorte également son OS pour téléphone mobile

C'est vrai, c'est un peu une perte de temps: au final, un OS mobile pour avoir du succès doit avant tout avoir un catalogue d'applications assez étoffé.

MrPatator, le 06/02/2012 - 14:03

Donc ca impose de garder la com ouverte, donc c'est aussi inadapté pour un appareil mobile si on ne veut pas bouffer son forfait et sa batterie.

Je ne sais pas.
Par exemple, un échange à base de XML (ou JSON), sur du HTTP, ça demande des ressources : parsing des données (que ça soit XML ou JSON, ou autre), bande passante (tous les headers HTTP, à chaque requête, ça doit bouffer un peu, mine de rien).
J'avais cherché s'il y avait des tests qui mettaient face à face les websockets et les appels ajax classiques, sur des questions de performance (utilisation du processeur, de la batterie, de la bande passante etc.), mais je n'avais pas trouvé.
Si quelqu'un a une source...

systèmes fermés comme iOS ou Android

J'ai ri.

le push impliquerai les fournisseur à relayer le push ou à ouvrir l'upload
mais comme leur beurre c'est la BP , y a peu de risque qu'ils le fassent volontairement.

Guillaume, le 06/02/2012 - 12:41

La Fondation Mozilla, qui édite le navigateur Firefox et travaille sur son système d'exploitation mobile Boot To Gecko, veut offrir aux développeurs d'applications web la possibilité d'envoyer des notifications comme le font les applications propriétaires sur les systèmes fermés comme iOS ou Android.

Applications "propriétaires" et systèmes "fermés". Oui super mais ces qualificatifs n'ont strictement rien avoir avec le sujet.
D'ailleurs si je prends au hasard Ubuntu qui est un système "libre et ouvert", j'ai actuellement pas non plus de notification depuis les applis web d'un navigateur. Dois-je en conclure que certaines distributions sont privatrices de liberté ?

Non tout ceci n'est qu'une histoire de proposer un protocole qui devra être soumis au W3C et aux différents concepteurs d'OS pour être ensuite accepté et implémenté.

Guillaume, le 06/02/2012 - 12:41

Si l'on focalise beaucoup sur la concurrence que se livrent les systèmes d'exploitation iOS, Android ou Windows Phone, on en oublie trop vite que la véritable bataille se joue à une plus large échelle entre deux visions de l'avenir de l'informatique.

Mais ça y est vous retombez encore dans vos psychoses totalitaires à deux balles.
Pourquoi il n'y aurait que deux visions de l'informatique ? Pourquoi devrait-on obligatoirement choisir un camp ? Et pourquoi ne pas imaginer de cohabitation ? C'est d'ailleurs ce que fait tout le monde (ou presque).
Sur mon ordinateur ou smartphone, j'utilise des applications mais aussi le web. Je choisis juste en fonction de ce que je trouve de mieux. Je me fais pas comme vous un intégriste à oeillère...

Guillaume, le 06/02/2012 - 12:41

La première vise à imposer des catalogues centralisés d'applications propriétaires qui ne fonctionnent que sur une plateforme, et ne sont distribuées que sur une place de marché, qu'elle soit imposée (l'App Store d'Apple) ou fortement suggérée (l'Android Market de Google).

"Imposée" ? Sauf que le client dispose ! Qui oblige à avoir un iPhone ? Personne ! Qui oblige à télécharger plein d'applications ? Personne non plus !
Non il a été proposé au client un modèle, et le client l'a trouvé très bien. On peut même parler de plébiscite...

Cela ne vous plaît pas ? Aucune importance puisque vous n'êtes pas le centre du monde et avez toute liberté d'aller ailleurs. D'autant que vous présentez les choses de façon fallacieuse: vous faites croire à l'obligation de passer par l'AppStore alors qu'Apple produit et intègre un excellent navigateur HTML5 à iOS (et donne même des exemples sur son site développeur pour faire des applications avec !).

Bref, le choix existe autant pour les programmeurs que les clients. Mais si tout ce petit monde préfère en rester aux applis c'est peut-être parce que ses dernières ont des avantages que le web n'a pas (performances, facilité à la monétisation, look & feel, ...).

Attention aussi à ne pas confondre l'informatique mobile, de l'informatique sur les ordinateurs. Les usages et l'ergonomie diffèrent, on ne peut donc pas généraliser...

Guillaume, le 06/02/2012 - 12:41

La seconde vision vise à imposer une informatique ouverte

"Imposer" ?

Ah ben tiens il semble que dans le camp d'en face on considère comme normal ce qu'on critique chez l'opposant...

Guillaume, le 06/02/2012 - 12:41

voir à ce sujet la décision du Financial Times de passer intégralement en HTML5

Rien à voir avec une question d'éthique et de censure, mais juste une histoire de gros sous. Pas question de reverser un centime à Apple (même si c'est ce dernier qui a créé un marché des tablettes qui n'existait pas auparavant), et au moins le FT a toute liberté de revendre les données personnelles de ses abonnés.
Je trouve donc très amusant que Numérama vienne défendre les intérêts économiques des majors de l'édition et s'indigner qu'on ne puisse pas bafouer les droits des utilisateurs à sa guise.
Bref Numérama est prête à renier à 100% ses principes dès que le mot "Apple" se glisse dans le sujet.

Guillaume, le 06/02/2012 - 12:41

Mais Mozilla veut aussi priver les systèmes fermés de cet avantage concurrentiel. Jeff Balogh, développeur chez Mozilla, a présenté sur son blog le système de notifications sur lequel travaille la fondation. L'idée est de passer par une API qui servirait d'interface entre le service web et l'utilisateur à qui envoyer une notification.

Tiens après ce quart d'heure de lutte contre la démagogie, parlons technique.

Un détail qui a son importance: pour lancer une notification, une application qu'elle soit web ou native doit tourner tout le temps. Or par exemple iOS interdit qu'un navigateur s'amuse à faire tourner du Javascript en arrière-plan et/ou pour une longue durée. àa paraît logique le JS est ruineux du point de vue CPU. Et j'ose pas imaginer si on cumule les onglets d'appli web ouvertes !

Bref sur iOS ça ne marchera pas à cause des gardes-fous qu'a mis en place à Apple. Sur Android c'est pas comme ça et Mozilla pourra sortir n'importe quoi. Et l'utilisateur qui n'y comprend pas grand chose se retrouvera avec une autonomie ridicule. Tout ça parce qu'il faut singer les applications pour préserver le business de Mozilla.

Et le "BootToGecko" ça va intéresser qui ?

NeoBurner, le 06/02/2012 - 14:45

systèmes fermés comme iOS ou Android

J'ai ri.

Le pire, c'est qu'on dirait qu'ils vont même pas le modifier.

Le, le 06/02/2012 - 15:41

Bref sur iOS ça ne marchera pas à cause des gardes-fous qu'a mis en place à Apple. Sur Android c'est pas comme ça et Mozilla pourra sortir n'importe quoi.

A ma connaissance, le javascript n'est pas exécuté quand le navigateur d'android est en arrière-plan.

Edit : Je viens de vérifier, et visiblement, il n'est effectivement pas exécuté...

ça m'a l'air bien tordu pour faire la même chose qu'une lecture ajax, un flux RSS ou au pire la réception d'un SMS ou d'un email.

Je suis a 100% pour une concurrence déployé au maximum et qui en plus pousserait les dévellopeurs a faire de l'HTML5 mais aujoud'hui avec un WebOs résolument tourné vers le Web qui passera OpenSource bientôt ce serait peut-être l'ocasin pour Mozilla de partir sur une base intéressante.
Malgré la concurrence Webkit / Gecko

Chouette! Un nouveau moyen de fidéliser nos consommateurs et de leur faire mieux connaître nos produits au travers d'une expérience riche et engageante.

TuXiC69, le 06/02/2012 - 12:23

Je ne suis pas sûr d'avoir bien compris : si l'utilisateur (ou plutôt l'application cliente) doit aller consulter une url, alors ce n'est pas du push, si ?
Pour moi avec du push c'est le serveur qui initie l'envoi des notifs au client, et pas le client qui vient les chercher. Corrigez moi si je me suis planté.

Ton raison n'est pas bancale, c'est juste que techniquement on peut gruger.
Lorsque le client se connecte sur l'URL le serveur peut très bien ne pas répondre... on envoyer une réponse HTTP "partial content" pour maintenir la connexion ouverte et n'envoyer des notif que quand il y en a effectivement une. Quid de la consommation? Une entrée de plus dans la pile TCP mais sinon ça ne consomme vraiment rien

tel que j'ai compris l'article il y a bien du "vrai" push mais pas que.
une api est livré aux sites web pour faire du push vers le client, mais ne sachant pas sur quel périphérique/media, une url unique au client est fournie, celle ci pointe sur un serveur (de mozilla ou pas) qui s'occupe de centraliser toutes les notifications, ensuite libre a vous de faire un client, pour téléphone, une extension Firefox, ou tout autre client de votre choix, qui viendra s'appuyer sur ce serveur de centralisation. Donc c'est un système push/pull.