Mon blog

Pour tous ceux qui sont désormais :-) convaincus de l'utilité d'Unicode (parce qu'ils travaillent dans un environnement non-anglo-saxon ou simplement parce qu'ils sont sensibles à la diversité culturelle du monde), voici un livre qui évitera de se cogner le texte de la norme. Celle-ci n'est pas incompréhensible (un peu plus austère qu'un RFC mais beaucoup moins que les normes ITU/ISO) mais c'est une norme, elle n'a pas de vocation pédagogique.

Le livre de Gillam, au contraire, se veut une introduction pratique et claire à Unicode, et notamment aux problèmes pratiques que pose son déploiement. Il cible les programmeurs d'abord, les ingénieurs système et réseaux ensuite.

Il explique très bien les concepts de base d'Unicode (si différents des autres jeux de caractère que beaucoup de bêtises ont été écrites par des informaticiens n'ayant rien compris à Unicode) et il a notamment une utilisation originale du modèle en couches appliqué aux jeux de caractères (Unicode a cinq couches).

Le chapitre historique est passionnant, avec plein de détails sur les techniques d'encodage (un encodage n'est pas juste un choix arbitraire de bits pour représenter une information, il a des avantages et des inconvénients).

Les sujets très difficiles de la canonicalisation ("masse" est-il l'équivalent de "maße" ?) ou de la bidirectionnalité ("Avram said 'Mazel Tov', and smiled", avec la phrase du milieu en hébreu) sont très bien traités, très clairs.

Une grande (peut-être trop grande, mais c'est la taille d'Unicode qui est en cause) partie est consacrée à l'examen de beaucoup d'écritures, avec leurs particularités (il n'existe pas une écriture sans au moins une idiosyncrasie gênante à implémenter, pas une langue qui ne rajoute ses propres variations ; vous connaissiez le "French accent sorting" ?). Un voyage passionnant, et plein de jolis dessins.

Les derniers chapitres, consacrés à l'implémentation, raviront ceux qui se souviennent avec émotion du cours de Structures de Données à la fac. Plein de solutions rigolotes et détaillées à des problèmes spécifiques à Unicode (la plupart des opérations nécessitent une table, contrairement à ASCII, et il n'est pas évident de gérer une table de 2^21 entrées). On y retrouve même le « trie » des routeurs IP, qui sert aussi, par exemple, aux conversions de l'alphabet latin tapé au clavier en cyrillique (car il y a la meme règle du longest match).

La plupart des codes sont en Java mais aucun gadget objet n'est utilisé et ces exemples sont facilement compréhensibles.

Quelques critiques : le chapitre 1 est bâclé (confondant Unicode et UTF-16) et contredit le texte ultérieur (qui explique bien la différence). Il y a des erreurs manifestes concernant le monde Internet qu'il connait évidemment peu (le livre d'Andries est bien meilleur sur ce point). Et la dernière partie sur le support d'Unicode dans les langages de programmation et dans les systèmes d'exploitation n'est qu'une synthèse d'informations officielles, dans un domaine où tout système prétend être Unicode et où le diable est dans les détails (quel niveau de support Unicode, exactement ?)

Alors qu'il existe plein de livres sur tel ou tel SGBD et ses fonctions rigolotes (une dizaine d'O'Reilly différents pour Oracle, quatre livres sur PostgreSQL, qui n'en avait aucun un an auparavant), il existe peu de livres se concentrant sur le langage SQL et ses caractéristiques indépendantes du SGBD.

Bien sûr, on peut toujours lire le standard lui-même. D'abord, il faut le trouver (ce n'est pas un RFC, il n'est pas en ligne, il semble qu'on ne puisse même pas obtenir une forme machine, même en payant). Ensuite, il faut le lire. Des centaines de pages écrites serrées, sans souci pédagogique, avec un vocabulaire complètement non standard (comme "authID" au lieu de "user").

Bref, un guide est le bienvenu. "A guide to the SQL standard" ne vise pas les débutants complets, ni ceux qui veulent une solution pratique tout de suite. C'est plutôt un livre pour ceux qui veulent approfondir les choses, un livre pour les language lawyers qui adorent discuter pendant des heures un détail de la norme, mais qui manquent de tripes pour lire la norme elle-même.

On y trouvera tous les concepts du SQL standard (et c'est toujours un sujet d'émerveillement de voir que les choses les plus utiles de SQL comme les stored procedures sont absolument non standards), chacun détaillé en profondeur avec beaucoup d'exemples.

La discussion sur NULL, qui a introduit la logique tri-valuée dans SQL (vrai, faux, bof), est très représentative : c'est fou ce qu'une décision aussi simple peut entrainer comme conséquences. Un quizz pour les pros de SQL : s'il y a des NULL dans les tuples récupérés, est-ce que COUNT(*) et AVG(*) ignorent les NULL ou pas ? (La discussion figure dans le livre.)

Le livre n'est pas tout récent, et j'ignore ce qui s'est fait en matière de normalisation SQL depuis quelques années, donc il y a peut-être des changements. Les exemples de SQL embarqué sont écrit en PL/1 :-)

Ce livre (également disponible en ligne pour ceux qui veulent laisser leurs arbres aux petits écureuils pour l'hiver) est écrit par un übergourou SGML et XML, Norman Walsh, l'auteur des "DocBook stylesheets", inlassablement actif sur les listes de diffusion des logiciels libres.

Vous voulez écrire des documents structurés et pas des jolies notes de service ? Vous voulez faire des documentations traitables par programme, publiables sur le Web comme en papier, cherchables et éditables avec du logiciel libre ? Vous voulez rentrer dans l'avenir comme quasiment tous les projets de logiciel libre, qui utilisent DocBook pour leur documentation ? Alors, vous pouvez commencer par ce livre.

SGML a toujours fait peur, et pas à tort. XML bénéficie d'un baratin marketing d'enfer... mais qui ne se traduit pas toujours en pratique. Alors, si vous avez déjà essayé de lire la norme DocBook sans y parvenir, ce livre va vous aider, vous guider et vous fournir la référence sympa, avec exemples, pour naviguer dans les 3 ou 400 éléments que définit DocBook.

Le chapitre sur les adaptations de DocBook (une des forces de cette norme) est particulièrement clair et complet.

Après ce livre, vous ne ferez plus de docs en nroff.

Le titre est trompeur : le livre parle peu de cette soupe marketing jamais définie clairement qu'est le "HTML dynamique". C'est en fait un livre de référence sur les techniques Web, HTML, bien sûr, mais aussi CSS, DOM et Javascript.

Par exemple, pour HTML, le livre décrit chaque élément, ses attributs (standards ou pas), sa place dans DOM, sa présence ou pas dans tel ou tel navigateur, etc. Le truc à lire quant on sèche devant son code HTML, à se demander quel élément utiliser. (Les fanas de lecture sur l'écran utiliseront l'excellent HTML Help.)

Cette exhaustivité est particulièrement utile pour CSS, où le support selon les navigateurs est... très... variable.

La taille du livre, 1398 pages, donne une idée du désordre qu'est le Web. Vivement XML :-)

Vous avez toujours révé de concevoir un protocole ? De faire le nouveau SMTP ou le nouveau IPP ? Mais vous reculez devant la quantité de détails qu'il va falloir traiter, la sécurité, l'encodage, le multiplexage, tout cela en plus du problème que votre protocole doit résoudre ? Alors, BEEP ("Blocks Extensible Exchange Protocol", RFC 3080) est fait pour vous.

BEEP est un outil pour les concepteurs de protocole. Il fournit un cadre (framework) de description des protocoles (l'utilisation de ce cadre permet plus facilement aux relecteurs de comprendre les spécificités de ce protocole, sans se perdre dans des détails) et un ensemble de services tout faits, que vous pouvez utiliser tel quel. Par exemple, vous voulez de la confidentialité ? Vous spécifiez juste que votre protocole peut utiliser le profil TLS de BEEP et, sans autre effort de spécification (ou de codage), vous avez un mécanisme de confidentialité éprouvé et reconnu, qui fera que vous ne perdrez pas de temps à l'IETF à expliquer votre solution de sécurité.

Bref, BEEP est le retour de la couche session du modèle ISO :-)

Le livre, par l'auteur bien connu de BEEP (qui se vante du nombre de RFC qu'il a écrit, ce que je trouve assez vulgaire, style "la mienne est plus grosse que la tienne"), décrit les concepts de BEEP (sessions, canaux, messages) le mécanisme de tuning (qui permet d'"améliorer" un canal, par exemple en y démarrant TLS), la modélisation des échanges (requête-réponse, comme les RPC ou bien autre), et présente l'utilisation de BEEP pour faire un syslog fiable (RFC 3195). Des mises en oeuvre en Java, C et TCL permettent au techos de base de se faire une meilleure idée.

Vous en étiez resté au routage des paquets IP ? Vous envoyez toujours des bits et pas des messages structurés ? Il est temps de passer à Jabber, qui route des éléments XML et plus de simples 0 ou 1.

Connu surtout à l'origine comme plate-forme pour développer des applications de messagerie instantanée (genre ICQ), Jabber a évolué pour devenir un protocole de transport et de routage d'informations structurées, en XML en l'occurrence. Jabber peut servir de transport à des protocoles applicatifs ou à des protocoles plutôt session comme SOAP (un exemple XML-RPC figure dans le livre).

Le livre décrit le protocole, le serveur, la façon dont se prennent les décisions de routage. Beaucoup d'exemple de clients Jabber dans tous les langages, ainsi que des composants de serveur Jabber (des plug-ins du serveur assurant telle ou telle fonction) sont décrits en grand détail.

La lecture de l'été si vous maitrisez HTTP et que ce protocole commence à vous sembler ennuyeux.

Si vous croyez que faire un site Web, c'est taper du HTML (ou du Javascript, ou du PHP), voici un livre pour parler de ceux dont on ne parle jamais : les utilisateurs. Tout ce que le webmestre doit savoir sur les utilisateurs de son site. Comment tester leurs réactions, comment faire en sorte que cela marche pour ceux qui "ne veulent pas penser".

Pour les culturés, le livre de Jakob Nielsen Designing Web usability, couvre le même genre de problèmes. Krug est plus léger, moins universitaire et son livre fait honneur à son titre.

Ce livre est, à ma connaissance, le premier vrai bouquin entièrement écrit sur des arbres morts qui soit consacré uniquement au DNS, pas à sa partie technique (couverte par le O'Reilly) mais à sa partie politique et aux luttes autour de la gestion de la racine (il englobe sous ce terme la gestion du DNS et celles des adresses IP, malheureusement comme toujours le parent pauvre de ces discussions).

Il est écrit d'un point de vue des sciences humaines (droit, économie, science politique, que Mueller convoque pour analyser la formation de la fameuse gouvernance Internet) mais la partie technique a été bien relue et, quoique il y a des erreurs amusantes, elles ne sont pas graves.

Un chapitre 2 très bien fait remet le problème dans le cadre plus général de la gestion des identificateurs (dont le DNS n'est qu'un cas particulier) et analyse pourquoi les adresses Ethernet n'ont jamais déclenché de telles bagarres.

Ensuite, la partie historique est très détaillée, puisque Mueller reprend le problème à sa base, quant Postel avait un coin de bureau et pas de secrétaire pour gérer la racine. On y retrouve les grands moments de l'Internet, du IAHC au gTLD-MOU en passant par le "détournement" de la racine qu'avait tenté Postel.

Mueller n'a pas le défaut courant chez beaucoup de juristes et de politiques qui consiste à prendre pour argent comptant les déclarations publiques et les statuts formels. Analysant ceux de l'ICANN il note que les principales caractéristiques de l'ICANN (notamment le poids du gouvernement US) sont justement non-écrites.

Ensuite, le chapitre 11 passe à la politique. Ici, Mueller ne prend plus de gants. Il réagit en tant que défenseur de la liberté contre les prétentions exorbitantes des propriétaires de marques déposées qui tentent de profiter de l'institutionnalisation de la racine pour s'approprier des pouvoirs supplémentaires, en extension considérable du rôle original des marques. (Les lecteurs de Lawrence Lessig, souvent cité, retrouveront beaucoup de thèmes communs entre ces deux universitaires.)

La conclusion est un mélange de pessimisme et d'optimisme. Je cite le dernier paragraphe, qui conclut un chapitre expliquant qu'il semble difficile de revenir sur la prise du pouvoir par la Fédération du Commerce : But no doubt there are other technologies and systems hatching somewhere, ready to take the world by surprise.