HTML5 with Peter Lubbers 3/3

Ce billet est le troisième et dernier sur le compte rendu de la soirée avec Peter Lubbers hébergée par Zenika le 7 juin dernier. Reprenons où nous avions laissé ce compte-rendu.

WebSocket

C'est une nouveauté “invisible” qui concerne plutôt la communication sous jacente. Http, le protocole de communication qui sert les documents HTML n'a pas été conçu pour ce que l'on appelle aujourd'hui le “Real-time” web qui nécessiterait plutôt un protocole connecté de type Socket. Avec Http, on ne peut qu'envoyer une requête à laquelle un serveur répond. Pour obtenir une dynamique côté client, on serait tenté de faire des rafraichissements de page. Le problème, c'est qu'à chaque fois, on obtient des tas d'informations dans les entêtes. Cela génère du trafic inutile et augmente la latence. Des stratégies ont tout de même été mises en place pour lutter contre cet aspect asynchrone du protocole http. Avec Ajax par exemple, on peut faire du “polling”. C'est une stratégie qui consiste à interroger régulièrement le serveur pour mettre à jour le client. Même si le service est rendu, Peter nous a fait remarquer ce c'est très inefficace et cela ne tiens pas la charge. Merci à Peter pour nous faire partager un exemple réel sur le site facebook. La fonctionnalité de chat de facebook qui utilise le polling ajax nécessite 10.000 serveurs pour tenir la charge de ses utilisateurs.

WebSocket est donc la spécification qui se propose de résoudre ce problème. La société Kaazing dans laquelle Peter travaille a participé activement à cette spécification. Il nous en a résumé les caractéristiques:

• Full-Duplex Socket (communication montante et descendante simultanée) dans le navigateur. Vous ouvrez une connexion persistante entre le navigateur et le serveur web.
• L'initialisation de la connexion (“hand-shaking”) se fait toujours à partir du protocole http. Ça reste donc compatible avec une infrastructure web existante, on ajoute juste un client qui sait parler le WebSocket et un serveur également compatible.
• Permet des requêtes sur l'autres serveurs que celui qui a transmis l'application web originale. C'était une “lacune” des requêtes Ajax.
• La réduction de la quantité d'information non nécessaire transmises dans les entêtes peut aller jusqu'à 1/1000 dans les tests effectués par Kaazing.
  Les usages de ce protocole pourraient être par exemple l'édition simultanée à un google doc par plusieurs personnes. Ce serait irréaliste avec http si chaque caractère tapé émettait sa propre requête http.
• WebSocket permet aussi de faire passer des protocoles de plus haut niveau comme XMPP par exemple pour la messagerie instantanée ou encore d'autres protocoles client-serveur qui seraient utilisés dans le SI.

Peter nous montre ensuite dans le domaine du jeu vidéo, l'exemple du portage de Quake2 qui utilise WebGL et WebSocket. Chez Kaazing, ils ont écrit un client VNC dans le navigateur basé sur WebSocket ce qui évite d'installer un client VNC pour accéder à un partage d'écran.

Pour une démo, rendez-vous sur la page d'accueil de kaazing ou sur leur site de poker en ligne basé sur HTML5.

Geolocation

Cette API permet à une application web de connaître la localisation géographique de l'utilisateur. L'utilisateur peut tout de même refuser de transmettre sa position auquel cas, l'application devra échouer en gérant agréablement ce cas de figure (par exemple en affichant un message). L'application peut donc avoir accès aux coordonnées géographiques de l'utilisateur (et la précision) quel que soit le moyen que le navigateur emploie pour trouver cette position:

• dispositif de positionnement par satellite type GPS,
• triangularisation GSM lorsqu'on est en mobilité,
• ou géo-codage de l'adresse postale du point d'accès à internet déduit à partir de l'IP de l'utilisateur.

On peut aussi avoir accès à d'autres méta données telles que l'altitude ou la vitesse, toujours dépendantes du matériel dont dispose l'utilisateur pour accéder à l'application web.

Chacun de ces dispositifs a des avantages et des inconvénients. Par exemple, le GPS est la solution de positionnement la plus précise mais elle consomme beaucoup d'énergie, ce qui peut se révéler critique pour suivre un trajet pendant longtemps. Le wifi quant à lui est la plupart du temps payent. La résolution à partir de l'IP est rapide mais n'est pas très précise.

Web Storage

Pensez à cette API comme un moyen pour une page de stocker des données directement. Dans la version actuelle de HTML, on dispose déjà des cookies pour faire se genre d'opérations. Peter nous fait la citation de quelqu'un qui aurait qualifié l'API Web Storage de “Cookies dopés” (mieux en anglais “Cookies on Steroïds”).

Cette fois, un volume beaucoup plus important peut être stoké dans le “Local Storage” (stockage local) et le Session Storage (stockage dans la session) ou la base de données. Cela fait trois type de stockage. Les deux premiers sont des stockages associatifs de type “clé-valeurs”. Le troisième est une base de données WebSQL. La force de cette API est donc de pouvoir alléger les échanges réseaux puisque l'on crée un stockage local de données qui n'ont pas à transiter sur le réseau. De plus, les données sont persistées entre deux démarrages du navigateur ce qui permet de prolonger l'état de la navigation de l'utilisateur.

Le problème avec les cookies, ce sont leur taille fixe. Par exemple, sur un site de voyage qui stocke la commande de l'utilisateur dans un cookie, on peut arriver aux limites de stockage et celà entraîne une rupture de navigation et une perte de données pour le visiteur. Avec cette API, on a beaucoup plus de place. Peter avance aussi l'argument de la sous-exploitation de nos machines. Autant que les sites web puissent profiter de l'espace disque de plus en plus grand sur nos ordinateurs pour ne pas se contenter de simples terminaux web. Dans les implémentations actuelles de l'API, on a accès à une vue qui permet de visualiser ce que les sites web ont stockés dans l'espace du navigateur.

A propos du WebSQL, la spécification est au point mort car il n'y a pas vraiment d'intéret en fait pour spécifier encore un autre dialecte SQL…

Autres API de communication

• Server-sent events: Cela standardise l'envoi de données en broadcast du serveur au client. C'est le mode 'Comet' qui permet de recevoir des données sans en faire la requête.
• Cross-document messaging: Cela permet de faire des échanges dans une page (du document principal vers un iframe par exemple) en permettant le partage de contexte javascript.
• XHR Level 2 : C'est la nouvelle version de l'objet javascript qui apporte le support d'Ajax. Il est possible maintenant de faire des requêtes à d'autres serveurs qui sont hébergés sur d'autres domaines que celui qui héberge votre script.

Selon Peter, ces APIs sont intéressantes. Il les met tout de même en perspective par rapport à WebSocket qu'il considère comme plus puissant puisqu'il permet de mettre en oeuvre une connection TCP entre un client et un serveur.

Autres nouveautés

• Offline web applications : C'est plus que le cache actuel qu'on peut trouver dans les navigateur. Avec cette fonction, on spécifie au navigateur qu'une sous-partie du site doit être accessible offline. On décrit cela à travers un fichier cache-manifest.xml à la racine du site. On peut aussi savoir si le navigateur est on-line ou off-line, ce qui permet de réagir applicativement.
• Drag-and-Drop,
• History API : apporte un contrôle plus fin sur les bouton précédents et suivants pour historiser la navigation de l'utilisateur.
• Content editable

Vous pouvez trouver sur ce billet la présentation PDF de Peter Lubbers. Merci à lui pour cette présentation très complète sur l'état de HTML5.

---