From 798954d25558936474367aadea4f72e21eed5a7f Mon Sep 17 00:00:00 2001 From: RochDLY Date: Thu, 29 Feb 2024 21:24:30 +0100 Subject: =?UTF-8?q?mise=20=C3=A0=20jour=20de=20la=20version=20html?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...-01-12-l-ecriture-numerique-est-collective.html | 122 ++++++++++++++++++--- 1 file changed, 106 insertions(+), 16 deletions(-) (limited to 'docs/posts/2024-01-12-l-ecriture-numerique-est-collective.html') diff --git a/docs/posts/2024-01-12-l-ecriture-numerique-est-collective.html b/docs/posts/2024-01-12-l-ecriture-numerique-est-collective.html index 497d271..e9e42cb 100644 --- a/docs/posts/2024-01-12-l-ecriture-numerique-est-collective.html +++ b/docs/posts/2024-01-12-l-ecriture-numerique-est-collective.html @@ -49,7 +49,7 @@
  • Conclusion
    • @@ -121,7 +121,7 @@

    L’encodage et le décodage des caractères accompagne toute l’histoire de l’informatique (et du numérique). Au prémices de l’informatique, chaque matériel comportait ses propres programmes et tables d’encodage, rendant ainsi possible la transposition des données d’un matériel à un autre. Cependant, dans la plupart des cas, les données ne pouvaient pas circuler entre les différents modèles d’ordinateur, ou alors au moyen de transformations fastidieuses, rendant ainsi les traitements réalisés sur les données enfermés dans des silos. La norme ASCII (American Standard Code for Information Interchange) fait sont apparition dans les années 1960 pour résoudre les enjeux liés à l’encodage des données. Soumise à l’American Standards Association (d’abord ASA puis ANSI) en 1961 par l’un de ses inventeurs, Bob Bemer, puis approuvée en 1963, l’ASCII permet d’encoder 128 caractères sur 7 bits. Néanmoins, ce n’est pas parce qu’un encodage est reconnue en tant que norme que son usage est effectif à l’instant même de la reconnaissance. Il faut attendre 1968 que le président des États-Unis Johnson demande à ce que l’ASCII devienne la norme fédérale d’encodage des informations afin de réduire les incompatibilités au sein des réseaux de télécommunications pour qu’elle commence à se répandre. Dès 1969, tous les ordinateurs achetés par le gouvernement des États-Unis étaient compatibles avec la norme ASCII. Du côté des ordinateurs personnels, il faudra attendre le début des années 1980 pour que cette norme se répande grâce, entre autre, à son implémentation dans les ordinateurs construits par IBM. La norme X3.4:1986 en vigueur aujourd’hui, a été déposée auprès de l’ANSI en 1986. C’est à partir de cette norme que d’autres ont été développées et sont compatibles ASCII, comme c’est par exemple le cas pour la norme Unicode, publiée en 1991, qui est la plus répandue de nos jours, car c’est elle qui encode le plus de caractères. Si ASCII contient 128 points de code, le standard Unicode permet d’en encoder plus de 149 000 sur une vingtaine de bits par point de code dans sa version 15.1 (de 2023). Afin de préserver cette compatiblité entre les normes, il est d’usage d’encoder les 128 premiers caractères de façon identique à la norme ASCII.

    Fonctionnement du software (les différentes piles)

    Bios, OS, Logiciels, réseaux (protocoles HTTP, TCP/IP, IMAP, POP, REST, GrapHQL), communication entre les différentes couches et fonctionnement de l’inscription dans le disque dur (HDD et SSD).

    -

    Pour le protocole HTTP, détailler un peu les différentes méthodes et la circulation des paquets

    +

    Le protocole HTTP a été conçu pour permettre la communication entre un client et un serveur. Les méthode de communication les plus couramment utilisée sont GET et POST. Par convention, et afin de limiter d’éventuels effets de bord, la méthode GET permet de récupérer des informations sur le serveur et de les afficher sur la page web tandis que POST permet de les envoyer depuis le client sur le serveur, soit pour ajouter une nouvelle entrée, soit pour la modifier.

    [Aux machines distantes (Serveurs, fibre optique, ADSL … Histoire de l’Internet physique)]

    Conclusion

    [Si j’écris la chaine de caractère “Hello world” elle passe par (décrire les éléments) jusqu’à cet encodage dans le disque dur, voir si l’écriture avec une autre architecture propose un encodage différent]

    @@ -259,21 +259,105 @@ L'affichage de l'écriture à l'écran respecte des conventions de lecture propr

    Les briques logicielles

    Ces trois formats pivots, Markdown, YAML et BibTeX, sont insérés dans tout un écosystème logiciel pour en permettre leur utilisation.

    Cette architexture logicielle est scindée en trois parties. Tout d’abord, nous retrouvons la base de données où sont stockées toutes les informations et données de Stylo : les comptes utilisateurs, les articles, les espaces de travail, les corpus, etc. Cette base de données est réalisée avec MongoDB, un système de gestion de base de données non relationnelle développé en 2007 et s’appuyant sur des documents structurés en JSON. Dans Stylo, la structure …

    -

    Le deuxième bloc de Stylo concerne l’interface que les utilisateurs voient affichée sur leur écran. Étant donné que Stylo est accessible via un navigateur web, l’interface a été conçue avec les technologies du web. On retrouve des objets en HTML, en CSS et en Javascript. Le framework React, une surcouche à Javascript open source développée par Facebook (aujourd’hui Meta) en 2013, a été employé pour réaliser les différents composants de l’interface et intégrer de nombreux modules tel que le module i18n qui permet d’implémenter le multilinguisme dans l’interface et changer la langue affichée à l’écran en un seul clic.

    -

    La base de données MongoDB n’est pas stockée dans le même espace que l’interface web. En conséquence, un système de communication devait être établi entre ces deux objets pour que les informations puissent être accessibles, à la fois en écriture et en lecture. Pour mettre en oeuvre cette communication, une API (Application Programming Interface) utilisant le langage de requête GraphQL a été mise en place et rendue accessible via le protocole HTTP (Hypertext Transfer Protocol)5, la surcouche du protocole internet utilisée pour le web. Le langage de requête et de manipulation GrapHQL a également été développé par Facebook à partir de 2012 puis publié en open source en 2015.

    -

    Le protocole HTTP a été conçu pour permettre la communication entre un client et un serveur. Les méthode de communication les plus couramment utilisée sont GET et POST. Par convention, et afin de limiter d’éventuels effets de bord, la méthode GET permet de récupérer des informations sur le serveur et de les afficher sur la page web tandis que POST permet de les envoyer depuis le client sur le serveur, soit pour ajouter une nouvelle entrée, soit pour la modifier.

    -

    La particularité d’une API GraphQL, contrairement à une API REST par exemple, est qu’elle sert l’ensemble des données à une seule adresse (endpoint) alors que plus généralement, les données sont accessibles à des URL très précises.

    -

    Plutôt que d’employer directement les méthodes GET et POST du protocole HTTP, deux types de requête sont utilisées avec la méthode POST pour effectuer les actions de lire et modifier le contenu de la base de données avec GraphQL. La requête de type query permet de récupérer les informations sur le serveur et celle de type mutation de les modifier.

    -

    [Rappeler les propriétés de chacun des types dans GET et POST, et ce que ça apporte aux informations qui transitent]

    -

    Le dernier bloc de Stylo est le module d’export qui permet de transformer les informations saisies et visibles dans l’éditeur en de multiples documents. Tout ce module réalisé avec le langage de programmation Python est développé et maintenu par David Larlet. Cette brique technologique est articulée autour du logiciel de transformation et de conversion Pandoc6 déployée sur un serveur et rendue accessible via une autre API7 fabriquée à partir de framework FastAPI8

    -

    Le module d’export intégré à Stylo9

    +

    Le deuxième bloc de Stylo concerne l’interface que les utilisateurs voient affichée sur leur écran. Étant donné que Stylo est accessible via un navigateur web, l’interface a été conçue avec les technologies du web. On retrouve des objets en HTML, en CSS et en Javascript. Le framework React, une surcouche à Javascript open source développée par Facebook (aujourd’hui Meta) en 2013, a été employé pour réaliser les différents composants de l’interface et intégrer de nombreux modules tel que le module i18n qui permet d’implémenter le multilinguisme dans l’interface et changer la langue affichée à l’écran en un seul clic. L’éditeur de texte, pièce maîtresse de Stylo, s’appuie sur la technologie Monaco5 développé par Microsoft et rendu disponible sous licence MIT.

    +

    La base de données MongoDB n’est pas stockée dans le même espace que l’interface web. En conséquence, un système de communication devait être établi entre ces deux objets pour que les informations puissent être accessibles, à la fois en écriture et en lecture. Pour mettre en oeuvre cette communication, une API (Application Programming Interface) utilisant le langage de requête GraphQL a été mise en place et rendue accessible via le protocole HTTP (Hypertext Transfer Protocol)6, la surcouche du protocole internet utilisée pour le web. Le langage de requête et de manipulation GrapHQL a également été développé par Facebook à partir de 2012 puis publié en open source en 2015.

    +

    L’une des particularités d’une API GraphQL, contrairement à une API REST par exemple, est qu’elle sert l’ensemble des données à une seule adresse (endpoint) alors que plus généralement, les données sont accessibles à des URL très précises ce qui a pour effet de rendre explicite la structuration des données dans la base. En ne servant les données qu’à une seule adresse, l’API s’échappe de la contrainte de la structuration des données et contourne les problèmes récurrents d’over-fetching ou d’under-fetching que l’on peut rencontrer dans certaines applications7. l’API GraphQL est agnostique vis-à-vis de la forme de la base de données. Par contre, la définition des requêtes adressables à la base de données doit être déclarée pour que l’on puisse faire circuler les informations. Pour cela, GraphQL à son propre langage de description de schéma (SDL, Schema Definition Language) et permet de déclarer explicitement les différentes façons d’écrire une requête.

    +

    Par exemple dans Stylo, le champ user contient les informations suivantes8 :

    + +

    Une requête simple consisterait à vouloir directement récupérer l’adresse courriel lié à mon compte utilisateur :

    +
    query user {
+  user {
+    email
+  }
+}
    +

    et renverrait comme réponse :

    +
    {
+  "data": {
+    "user": {
+      "email": "roch.delannay@umontreal.ca"
+    }
+  }
+}
    +

    Cet exemple montre qu’il y a une certaine économie de l’information implémentée dans le fonctionnement même de GraphQL pour n’aller chercher que les informations nécessaires pour une requête particulière, pour peu que la requête en elle-même soit bien rédigée. D’ailleurs, il s’agit là d’un des écueils potentiels de GraphQL : des requêtes mal formulées peuvent aller à l’encontre de cette économie.

    +

    Dans Stylo, chaque fonctionnalité, chaque bouton (ou presque) qui réalise une action de lecture ou d’écriture est lié à une requête GraphQL. Précédemment nous avons vu que le protocole HTTP comportait deux méthodes bien connues pour faire circuler des informations entre un client et un serveur : GET et POST. Un des arguments phares présenté par GraphQL est sa dimension agnostique par rapport au protocole de communication des informations employé, que ce soit HTTP ou des WebSockets ou autre. Pourtant, malgré la capacité de GraphQL à être utilisable avec toutes les méthodes d’HTTP9, une bonne pratique appliquée par la communauté GrapHQL est l’emploi du protocole HTTP couplé à la méthode POST pour tous types de requêtes (que ce soit une query, une mutation ou encore une subscription). Lors de la transmission des informations par la méthode GET, l’ensemble des informations sont insérées dans l’URL ce qui 1) les rend visibles (et vulnérable) et 2) impose une limite du nombre de caractères (au alentours de 2000 au maximum) au risque de déclencher une erreur 414 (URL trop longue). En conséquence, il est préférable d’utiliser la méthode POST pour récupérer des informations car elles ne seront ni visibles ni limitées en longueur, ce qui s’avère nécessaire pour des requêtes parfois trop longues. Malgré l’aspect agnostique de GraphQL, la forme textuelle des requêtes implique en elle-même un choix particulier de transmission des informations avec ce qu’il comporte comme avantages et inconvénients.

    +

    Les spécificités du protocoles HTTP sont définies dans les Request for Comments publiés par L’Internet Engineering Task Force (IETF) fondée en 1986, dont le siège se trouve aux États-Unis. Les documents et leurs contenus sont régulièrement mis à jour par la communauté qui participe à ces commentaires. Le numéro de la RFC en lien avec la méthode POST est le 911010 publié en juin 2022.

    +

    La méthode POST est définie dans le paragraphe 9.3.3 comme :

    +
    +

    The POST method requests that the target resource process the representation enclosed in the request according to the resource’s own specific semantics. For example, POST is used for the following functions (among others): - Providing a block of data, such as the fields entered into an HTML form, to a data-handling process; - Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles; - Creating a new resource that has yet to be identified by the origin server; and - Appending data to a resource’s existing representation(s).11

    +
    +

    À travers cette brève définition, l’on remarque que l’usage principal de la méthode POST est plutôt relative à l’envoi d’informations, qu’elles soient nouvelles ou mises à jour. Le comportement de POST fait toutefois débat, notamment quant à son usage pour l’envoi de certaines informations puisque, comme cela est indiqué dans sa définition, POST laisse le soin au serveur (la ressource cible) de traiter les données contenues dans son message selon sa propre sémantique. En somme, contrairement à d’autres méthodes comme PUT, POST n’est pas indempotente ce qui pourrait entraîner des différences de résultat lors de l’exécution d’une requête (par exemple, la duplication d’une requête en cas de problème de connexion).

    +

    Cependant, cette caractéristique tend à disparaître dans le cas d’une structure GraphQL puisque cette dernière ne dépend pas d’une architecture composée de multiples adresses (une pour chaque ressource) mais d’une seule adresse à laquelle on soumet des requêtes. Dans le cas de Stylo, POST est donc soumis à l’architecture de GraphQL, on peut alors bien considérer GraphQL agnostique à l’égard de la méthode POST du protocole HTTP.

    +

    Enfin, dans le cas d’une requête POST, le contenu à envoyer sur le serveur est formaté en JSON.

    +

    Ci-dessous un exemple de requête POST envoyée depuis l’interface Web de Stylo vers le serveur :

    +
    {"query":"query updateWorkingVersion($articleId: ID!, $content: WorkingVersionInput!) {\n
+article(article: $articleId) {\n
+updateWorkingVersion(content: $content) {\n
+updatedAt\n
+}\n
+}\n
+}",
+"variables":{"userId":"61d62c4978651b001208b7aa",
+"articleId":"65e0e38129637c001274ef7a",
+"content":{"md":"Ajout du texte pour la requête HTTP `POST`"}}}
    +

    Autrement dit, chaque fonctionnalité décrit de manière formelle la structuration des informations dans Stylo, donc ce que Stylo écrit dans la base de données et dans les textes puisque ce sont les informations renseignées qui seront intégrées dans les documents exportés. En ce sens, Stylo et les protocoles auxquels il est assujetti pré-construisent la totalité de ce qu’un utilisateur peut saisir dans l’interface et sera enregistré dans la base de données.

    +

    Le dernier bloc de Stylo est le module d’export qui permet de transformer les informations saisies et visibles dans l’éditeur en de multiples documents. Tout ce module réalisé avec le langage de programmation Python est développé et maintenu par David Larlet. Cette brique technologique est articulée autour du logiciel de transformation et de conversion Pandoc12 déployée sur un serveur et rendue accessible via une autre API13 fabriquée à partir de framework FastAPI14. Le module d’export intégré à Stylo15 permet de convertir et transformer les textes sources en une multitude d’artefacts, selon les capacités de transformation et de conversion du logiciel Pandoc auquel il est soumis. Les développements autour des transformations des sources de Stylo seront traitées dans le prochain chapitre, nous les laissons donc de côté pour l’instant.

    [Faire un shéma de toute la pile techno de Stylo]

    +

    Une description très générale des moyens de communication entre les différents modules qui composent Stylo nous montre déjà que l’information qui va être saisie dans cet éditeur de texte est formatée par une architecture de données alors que nous n’avons pas encore abordé les conditions mêmes de l’écriture à savoir les trois formats pivots d’un texte dans Stylo.

    Les formats pivots de Stylo en détail

    La sérialisation des métadonnées en YAML

    L’écriture en Markdown

    La saisie des références bibliographiques en BibTeX

    -

    Ce que Stylo permet ou non de faire

    +

    Écrire avec Stylo

    (Qu’est-ce que Stylo en tant qu’agent qui écrit ?) Dépassement du simple rapport de force énoncé précédemment (grâce à une transparence dans les actions de la machine et l’augmentation de la littératie numérique)

    +

    Finalement, après la description de certains des mécanismes à l’oeuvre dans Stylo, nous sommes en droit de nous demander comment se déroule le geste d’écriture dans cet environnement ?

    +

    Jusqu’à présent, nous savons que le texte est saisi par l’utilisateur en Markdown (YAML et BibTeX), puis est envoyé sur le serveur au moyen d’une requête GraphQL au format JSON contenue dans une requête HTTP utilisant la méthode POST comme mode de communication. Entre ces étapes persiste une phase que nous n’avons pas encore évoqué : la requête POST envoyé au serveur ne s’effectue pas en continu entre le client et le serveur (ce n’est pas un flux). Une phase latente se glisse dans l’interface Web entre le moment où l’utilisateur frappe les touches de son clavier et le moment où la base de données est mise à jour. Dans ce laps de temps, qu’advient-il du texte ?

    +

    Comme cela est mentionné précédemment, l’espace d’écriture est un espace web. Pour y accéder il nous faut un logiciel particulier – un navigateur ou un fureteur – capable d’intpréter du HTML, du CSS et d’exécuter du Javascript. Lorsque l’on écrit dans Stylo (et dans Monaco), le texte saisi doit être manipulable et interprétable par le navigateur pour pouvoir être envoyé sur le serveur. C’est le rôle de Monaco de traiter cette couche d’information. À l’écran, l’utilisateur voit s’afficher du Markdown tel qu’il le frappe, pourtant cette information n’est inscrite sur aucun support en dehors du rendu visuel affiché sur cet écran. Monaco travaille avec des modèles et ce sont avec ces modèles que l’utilisateur interagit. Chaque modèle est rattaché à une URI et c’est de cette manière que Monaco peut manipuler le DOM (Document Object Model) du navigateur pour créer le texte et son rendu graphique en texte brut.

    +

    Le DOM est une représentation abstraite d’un document HTML exécutée dans le navigateur. Tous les éléments structurés à l’intérieur de ce document deviennent des objets, des noeuds manipulables avec du Javascript. C’est grâce à ce procédé qu’une page web est rendue dynamique. Puisque le DOM dépend du navigateur, nous pouvons en déduire que ce document sera différent selon le navigateur et la version du logiciel utilisée.

    +

    Pour accéder à ce DOM il suffit d’ouvrir les outils de développements du navigateur et d’inspecter le contenu de la page HTML.

    +

    Ci-dessous, une première pour montrer le texte saisi à l’écran et une deuxième pour montrer ce qui est écrit dans le DOM :

    +
    +Exemple de texte saisi en Markdown dans Stylo + +
    +
    +DOM du texte saisi dans Stylo + +
    +

    L’état du texte inscrit dans le DOM est différent de celui qui apparaît à l’écran. Le Markdown se retrouve encapsulé dans des balises attribuées par l’éditeur Monaco et la syntaxe Markdown se retrouve à l’état de texte brut : la balise de titre de niveau 2 (##) n’a plus de valeur sémantique.

    +

    Écrire dans un environnement comme Stylo ne consiste pas seulement en une simple saisie du texte à l’écran. Lorsque j’ai l’impression d’écrire au format Markdown, nous écrivons avec Stylo un texte bien différent. Le texte affiché dans Stylo passe en réalité, d’un point de vue matériel, par au moins 4 représentations différentes :

    + +

    La seule saisie du texte dans Stylo nécessite en réalité une multitude d’étape intermédiaire cachée aux yeux de l’utilisateur mais que pourtant Stylo rédige et inscrit dans la mémoire numérique.

    +

    Chacun de ces états à une signification particulière. Le premier est la projection d’une structure de l’information, tandis que le deuxième en permet l’interprétation et l’affichage par le navigateur, la troisième est une représentation formatée pour circuler entre un client et un serveur et enfin la quatrième est à l’état de stockage, prête à être appelée pour faire le chemin en sens inverse.

    +

    Ces différents états du texte sont plus que de simples représentations, ce sont des documents différents et chacun a bien une signification qui lui est propre. Par exemple, la forme en Markdown brut ne peut pas circuler en l’état par le protocole HTTP, il lui manque toute une série d’informations : ce que Stylo écrit dans le texte.

    +

    Parmi ces quatre document produits pour écrire, seulement une l’est par l’utilisateur, les autres formes sont écrites par Stylo.

    Conclusion

    Dans ce chapitre, nous avons vu que …

    Nous avons vu que l’architexte n’est pas une entité à part, détachée de l’ordinateur, mais qu’il est l’ordinateur même et qu’il s’exprime/écrit sur son support à travers l’architexte, soit à travers un texte qui lui donne une série d’instructions sur comment lire et écrire.

    @@ -284,11 +368,17 @@ L'affichage de l'écriture à l'écran respecte des conventions de lecture propr

  • Cette machine a été conçue par Mario Bellini pour Olivetti en 1987, site consulté le 21 février 2024 https://www.moma.org/collection/works/3641↩︎

  • La première loi de Moore est relative à l’évolution des processeurs dans le temps et stipule que le nombre de transistors présent dans les processeurs doublera tous les ans pour un coût constant↩︎

  • Voir la page web correspondante sur le site d’Intel, consulté le 16 février 2024 : https://www.intel.fr/content/www/fr/fr/history/museum-story-of-intel-4004.html↩︎

    • -

  • L’endpoint de l’API GraphQl de Stylo est accessible ici : https://stylo.huma-num.fr/graphql↩︎

    • -

  • Pandoc est un incontournable pour transformer des documents. Il a été développé et maintenu en Haskell par son créateur John MacFarlane depuis 2006.↩︎

    • -

  • La pandoc-api est accessible à cet endpoint: https://pandoc-api.stylo.huma-num.fr/↩︎

    • -

  • FastAPI est disponible à cette adresse: https://fastapi.tiangolo.com/↩︎

    • -

  • On peut trouver le module d’export à cette URL : https://export.stylo.huma-num.fr/↩︎

    • +

  • Voir le site web https://microsoft.github.io/monaco-editor/, consulté lw 29 février 2024.↩︎

    • +

  • L’endpoint de l’API GraphQl de Stylo est accessible ici : https://stylo.huma-num.fr/graphql↩︎

    • +

  • Ces deux problèmes désignent soit une récupération trop importante de données (et nécessite un tri après récupération des données sur le serveur, soit un manque de données pour lequel il faut faire appel une deuxième fois ou plus au serveur pour en récupérer les données)↩︎

    • +

  • Le modélisation du schéma GraphQL est accessible sur le dépôt GitHub de Stylo à l’adresse suivante : https://github.com/EcrituresNumeriques/stylo/blob/master/graphql/models/user.js↩︎

    • +

  • Voir https://graphql.org/learn/serving-over-http/↩︎

    • +

  • Voir https://www.rfc-editor.org/rfc/rfc9110#name-introduction↩︎

    • +

  • Traduction personnelle : La méthode POST demande à la ressource cible de traiter la représentation incluse dans la demande selon sa propre sémantique. Par exemple, la méthode POST est utilisée pour les usages suivants (parmi d’autres): Fournir les blocs de données, comme les champs d’un formulaire HTML, à un traitement de données ; Publier un message sur un tableau d’affichage, un groupe d’échange, une liste de diffusion, un blog ou un groupe d’articles similaire ; Créer une nouvelle ressource qui n’a pas encore été identifiée par le serveur d’origine ; et Ajouter des données à la (aux) représentation(s) existante(s) d’une ressource.↩︎

    • +

  • Pandoc est un incontournable pour transformer des documents. Il a été développé et maintenu en Haskell par son créateur John MacFarlane depuis 2006.↩︎

    • +

  • La pandoc-api est accessible à cet endpoint: https://pandoc-api.stylo.huma-num.fr/↩︎

    • +

  • FastAPI est disponible à cette adresse: https://fastapi.tiangolo.com/↩︎

    • +

  • On peut trouver le module d’export à cette URL : https://export.stylo.huma-num.fr/↩︎

    • -- cgit v1.2.3