Lorsqu'un message est envoyé à un ami à l'aide du messager web, il passe d'un navigateur à l'autre sans être stocké sur nos serveurs. Plus exactement, il ne reste que quelques secondes en mémoire sur nos serveurs, juste le temps que le destinataire le récupère.
Dans ces conditions, comment ce message et les précédents de la conversation peuvent-ils s'afficher quand vous le demandez ?
De même, l'affichage de la barre du messager (barre dépliée, repliée, onglets ouverts, type de défilement) reste cohérent d'une page à l'autre. Pourtant ceci n'est stocké nulle part sur nos serveurs.
Même avec énormément d'utilisateurs, très peu de données et de traitements sont nécessaires côté serveur pour le bon fonctionnement du messager.
Le messager s'appuie en effet sur une fonction très pratique que l'on retrouve sur les navigateurs web courants, mais qui est pourtant très peu utilisée : le stockage local.
Internet Explorer : possible depuis IE 5.0 (1999), à l'aide de la propriété “userData”. IE 8 y ajoute les interfaces “globalStorage” et “sessionStorage”.
Firefox : possible depuis Firefox 2.0 (2006) à l'aide de “globalStorage” et “sessionStorage”.
Safari (Webkit) : possible depuis 2007 avec l'interface “localStorage” ainsi qu'une interface SQL complète et conforme aux derniers travaux concernant les spécifications HTML 5.
Notons que l'installation de Google Gears offre aussi la possibilité d'accéder à une base SQL locale, mais avec une interface spécifique.
Il ne fait aucun doute que Google Chrome héritera de ces fonctions lorsqu'il se basera sur une version plus récente Webkit.
Pour les navigateurs tels qu'Opera qui n'ont encore aucune fonction de stockage local, il reste une échappatoire : la machine virtuelle Flash, qui propose ceci depuis Flash 6 (2002).
Quelques bidouilles existent par ailleurs, telles que celles qui consistent à utiliser l'historique du navigateur, mais il est beaucoup plus fiable de se limiter à ce qui a été explicitement conçu pour cet usage.
C'est au premier abord un peu décourageant de voir que les interfaces diffèrent beaucoup d'un navigateur à l'autre. Mais le jeu en vaut la chandelle et sachant que les spécifications HTML 5 détaillent ce point, on peut raisonnablement espérer que les choses deviennent rapidement plus simples et plus homogènes.
Mais au fait, qu'est-ce-que ce fameux “stockage local” ?
On peut le comparer aux cookies : il associe du contenu à des clefs et l'ensemble est stocké par le navigateur, sur la machine cliente. Les cookies accusent malgré tout un âge certain. L'interface pour y accéder (en Javascript) est old school, ils ne permettent pas de mémoriser grand chose (“4 Ko should be enough for anybody”) et ils sont systématiquement transmis au serveur web à chaque requête sur la même zone. Le stockage local gomme tous ces défauts et y ajoute des raffinements bien utiles.
Pour notre messager, toutes les opérations liées au stockage local passent par un petit objet qui offre une interface commune pour différentes méthodes (localStorage, globalStorage, userData et Flash). Vous pouvez le trouver ici : persistent-storage.js et le code source du Flash qui est utilisé à défaut de fonction native se trouve ici : Flashare.hx
Voici un très simple exemple d'utilisation :
(function() {
var key = "key";
var storage;
function after_storage_is_ready() {
var previous_value = storage.get(key);
if (!previous_value) {
console.log("Aucune valeur precedente");
previous_value = "x";
} else {
console.log(previous_value);
}
storage.set(key, previous_value + "x");
}
storage = PersistentStorage.init();
PersistentStorage.wait_until_ready(after_storage_is_ready);
})();
À noter que les données stockées ne sont accessibles que depuis la même origine (sous-domaine / domaine / port). Ainsi la clef “key” de ce script chargé à partir d'une page de “www.skyrock.com” serait totalement distincte d'une clef nommée “key” chargée à partir d'une page de “devteam.skyrock.com” ou même de “skyrock.com” tout court.
Pour contourner ce problème, le messager crée une “IFRAME” invisible dont le contenu provient toujours de la même URL : http://skyrock.com/sm/proxy.html
C'est cet élément qui va effectuer les opérations de stockage local. Les données sont ainsi toujours associées à l'origine “skyrock.com” et sont donc communes à toutes les pages sur lesquelles l'utilisateur peut se trouver.
Faire communiquer le Javascript d'une page avec celui d'une page d'une autre origine (ex: www.skyrock.com et devteam.skyrock.com) nécessite quelques autres précautions qui, si vous le souhaitez, seront détaillées dans un autre article.
Dans ces conditions, comment ce message et les précédents de la conversation peuvent-ils s'afficher quand vous le demandez ?
De même, l'affichage de la barre du messager (barre dépliée, repliée, onglets ouverts, type de défilement) reste cohérent d'une page à l'autre. Pourtant ceci n'est stocké nulle part sur nos serveurs.
Même avec énormément d'utilisateurs, très peu de données et de traitements sont nécessaires côté serveur pour le bon fonctionnement du messager.
Le messager s'appuie en effet sur une fonction très pratique que l'on retrouve sur les navigateurs web courants, mais qui est pourtant très peu utilisée : le stockage local.
Internet Explorer : possible depuis IE 5.0 (1999), à l'aide de la propriété “userData”. IE 8 y ajoute les interfaces “globalStorage” et “sessionStorage”.
Firefox : possible depuis Firefox 2.0 (2006) à l'aide de “globalStorage” et “sessionStorage”.
Safari (Webkit) : possible depuis 2007 avec l'interface “localStorage” ainsi qu'une interface SQL complète et conforme aux derniers travaux concernant les spécifications HTML 5.
Notons que l'installation de Google Gears offre aussi la possibilité d'accéder à une base SQL locale, mais avec une interface spécifique.
Il ne fait aucun doute que Google Chrome héritera de ces fonctions lorsqu'il se basera sur une version plus récente Webkit.
Pour les navigateurs tels qu'Opera qui n'ont encore aucune fonction de stockage local, il reste une échappatoire : la machine virtuelle Flash, qui propose ceci depuis Flash 6 (2002).
Quelques bidouilles existent par ailleurs, telles que celles qui consistent à utiliser l'historique du navigateur, mais il est beaucoup plus fiable de se limiter à ce qui a été explicitement conçu pour cet usage.
C'est au premier abord un peu décourageant de voir que les interfaces diffèrent beaucoup d'un navigateur à l'autre. Mais le jeu en vaut la chandelle et sachant que les spécifications HTML 5 détaillent ce point, on peut raisonnablement espérer que les choses deviennent rapidement plus simples et plus homogènes.
Mais au fait, qu'est-ce-que ce fameux “stockage local” ?
On peut le comparer aux cookies : il associe du contenu à des clefs et l'ensemble est stocké par le navigateur, sur la machine cliente. Les cookies accusent malgré tout un âge certain. L'interface pour y accéder (en Javascript) est old school, ils ne permettent pas de mémoriser grand chose (“4 Ko should be enough for anybody”) et ils sont systématiquement transmis au serveur web à chaque requête sur la même zone. Le stockage local gomme tous ces défauts et y ajoute des raffinements bien utiles.
Pour notre messager, toutes les opérations liées au stockage local passent par un petit objet qui offre une interface commune pour différentes méthodes (localStorage, globalStorage, userData et Flash). Vous pouvez le trouver ici : persistent-storage.js et le code source du Flash qui est utilisé à défaut de fonction native se trouve ici : Flashare.hx
Voici un très simple exemple d'utilisation :
(function() {
var key = "key";
var storage;
function after_storage_is_ready() {
var previous_value = storage.get(key);
if (!previous_value) {
console.log("Aucune valeur precedente");
previous_value = "x";
} else {
console.log(previous_value);
}
storage.set(key, previous_value + "x");
}
storage = PersistentStorage.init();
PersistentStorage.wait_until_ready(after_storage_is_ready);
})();
À noter que les données stockées ne sont accessibles que depuis la même origine (sous-domaine / domaine / port). Ainsi la clef “key” de ce script chargé à partir d'une page de “www.skyrock.com” serait totalement distincte d'une clef nommée “key” chargée à partir d'une page de “devteam.skyrock.com” ou même de “skyrock.com” tout court.
Pour contourner ce problème, le messager crée une “IFRAME” invisible dont le contenu provient toujours de la même URL : http://skyrock.com/sm/proxy.html
C'est cet élément qui va effectuer les opérations de stockage local. Les données sont ainsi toujours associées à l'origine “skyrock.com” et sont donc communes à toutes les pages sur lesquelles l'utilisateur peut se trouver.
Faire communiquer le Javascript d'une page avec celui d'une page d'une autre origine (ex: www.skyrock.com et devteam.skyrock.com) nécessite quelques autres précautions qui, si vous le souhaitez, seront détaillées dans un autre article.
