Mot-clé - technique

Fil des billets - Fil des commentaires

mercredi 19 juin 2013

Passer les torrents à Transmission depuis elinks

Quand on travaille à distance sur des machines, on a parfois besoin d'utiliser des torrents pour distribuer en masse des données sans surcharger un serveur unique — par exemple, pour diffuser des mises à jour dans un parc informatique.

Le problème se pose quand il faut récupérer ces torrents sur un serveur web nécessitant une authentification : il faut alors gérer des cookies de session, parfois utiliser des formulaires, etc. Bref, quand une simple requête curl n'est humainement plus envisageable, il faut sortir le navigateur web.

Pour les torrents, j'utilise Transmission en mode serveur, naturellement; l'outil transmission-remote permet de le piloter. Mon navigateur web en mode texte de prédilection est elinks.

La technique consiste donc à plonger directement dans le site web — en utilisant les cookies d'authentification mémorisés par elinks — pour obtenir le lien de téléchargement du torrent, afin de le passer à transmission-remote qui dira quoi faire à transmission-daemon. Non, ce n'est pas aussi tordu que ça en a l'air, et ça répond parfaitement à bon nombre de situations du quotidien.

Elinks se configure très facilement via ~/.elinks/elinks.conf.

# déclaration du type mime des torrents
set mime.extension.torrent="application/x-bittorrent"

# on nomme un gestionnaire pour ce type mime; ici, tout simplement « bittorrent »
set mime.type.application.x-bittorrent = "bittorrent"

# elinks demandera confirmation avant de télécharger le torrent, et donc de le passer à transmission
set mime.handler.bittorrent.unix.ask = 1 
set mime.handler.bittorrent.unix-xwin.ask = 1 

# le téléchargement sera fait d'une façon non-bloquante dans elinks, car on a autre chose à faire.
# en même temps, un torrent est très petit, ça va vite à transférer
set mime.handler.bittorrent.unix.block = 0 
set mime.handler.bittorrent.unix-xwin.block = 0 

# on associe une commande externe au gestionnaire précédemment défini 
set mime.handler.bittorrent.unix.program = "transmission-remote --add %"
set mime.handler.bittorrent.unix-xwin.program = "transmission-remote --add %"

Les liens magnets seront gérés d'une même façon, excepté qu'on ne cible pas un type mime mais un protocole.

vendredi 7 octobre 2011

Attaque juridique sur la tz database et ses conséquences pour le monde entier

Qu’est-ce qui s’est passé ?

Ce 30 septembre 2011 s’est produit un événement rare, d’une ampleur catastrophique pour le monde entier. Et personne ne l’a su, en dehors d’informaticiens spécialisés (administrateurs systèmes, gestionnaires de distribution de logiciels, etc.) et compétents[1].

La législation sur la propriété intellectuelle a failli déstructurer non seulement internet, mais aussi la quasi totalité des ordinateurs du monde entier. Je n’ai pas l’habitude des exagérations inutiles, donc moi-même je me surprend à écrire des choses pareilles. Et pourtant, c’est vrai.

La société américaine Astrolabe qui publie des ouvrages d'astrologie et des atlas a abusé utilisé le droit américain sur la propriété intellectuelle pour mettre hors-ligne et faire cesser l’activité autour de la tz database. Cela ne vous parle absolument pas, et c’est normal : il s’agit d’une partie de l’informatique très précise qui ne concerne pas directement les utilisateurs finaux.

La tz database ?

La tz database est un ensemble d'informations techniques sur les fuseaux horaires dans le monde. Ces informations sont utilisées partout en informatique : Détail d'horloge murale

  • Chaque fois que vous indiquez la ville où vous vous trouvez, par exemple, Europe/Paris, vous utilisez la tz database.
  • Chaque fois qu'un de vos appareils se met à l'heure automatiquement, par exemple votre magnétoscope, vous utilisez la tz database.
  • Chaque fois que vous consultez un site web votre ordinateur et celui en face se réfèrent à la tz database.
  • Chaque fois que vous notez un rendez-vous dans votre agenda électronique, vous utilisez la tz database.
  • Chaque fois que vous dépendez d'un appareil médical qui permet de vous maintenir en vie, vous pouvez être sur qu'il utilise la tz database.
  • Chaque fois que vous téléphonez, vous utilisez la tz database.
  • Chaque fois que vous prenez l'avion, vous utilisez la tz database.
  • Chaque fois que vous allumez la lumière dans une pièce, vous pouvez être sur que c'est grâce à des ordinateurs qui utilisent la tz database.

La tz database a été mise en place par Arthur Olson en 1986, pour permettre de disposer en un seul d'endroit des informations nécessaires pour gérer la data et l'heure sur les dispositifs informatiques. Avoir une seule source d'information permit à l'époque de factoriser de nombreux efforts éparpillés et de résoudre les problèmes de synchronisation. Ce projet s'est révélé être tellement pratique qu'il a été ensuite utilisé par l'ensemble des équipements qui utilisent de l'informatique; et qui donc s'appuient sur la notion de temps. De nos jours, on retrouve l'utilisation de la tz database dans la quasi totalité des équipements informatiques.

La tz database est gérée dans la grande tradition du libre : ouverture et transparence totale. N'importe qui peut rejoindre le projet, discuter de la structuration des données, participer au travail de collecte et de vérification des informations, réfléchir sur l'évolution de la gestion du temps (année bissextile, ajout et retrait de seconde pour compenser la rotation de la Terre, etc). Il est donc aisé pour n'importe quelle personne de contrôler la qualité du travail accompli et de le réutiliser.

Par une de ces bizarreries dont l'histoire a le secret, la tz database est hébergée par le NIH, ce qui convient très bien. De plus, elle est libre de toute contrainte politique et ne dépend d'aucun organisme. Ce qui correspond parfaitement aux besoins [2].

La bonne gestion de la tz database est importante car chaque année plusieurs dizaines de modifications y sont apportées : des pays sont créés et supprimés, des décisions politiques sont mises en œuvre pour limiter la consommation d'énergie (horaire été/hiver), des zones géographiques sont réaménagées, des tremblements de terre affectent la rotation de la planète, etc.

Conséquences de l'attaque juridique sur la tz database

La tz database est alimentée par des informations publiques : des lois sont votées, des arrêtés sont pris, des calculs scientifiques sont publiés… Son contenu n'est donc pas soumis à de quelconques règles d'exclusivité. En fait, c'est même l'inverse : ces informations doivent absolument être diffusées. Et au niveau international, la question politique du temps est plutôt bien gérée. Bref, rien à signaler.

Tout le monde (ou presque) dépend des informations de cette base de données. L'armée, la police, les secours aux personnes, la médecine, les transports, les entreprises, les particuliers… il n'y a aucun domaine couvert par l'informatique qui ne soit pas concerné. Et donc, la législation sur la propriété intellectuelle a failli supprimer et bloquer tout usage ultérieur de ces informations. Vous réalisez maintenant ce qui a affolé les informaticiens ?

kilo-étalon

Supprimer cette base de données équivaut à supprimer le kilo-étalon du Bureau international des poids et mesures et à interdire l'usage de sa dimension. Il n'y aurait alors plus de référence pour calibrer les machines-outils, et les conséquences seraient aussi dramatiques qu'immédiates dans tous les secteurs. Il se passe actuellement une chose similaire au niveau du temps : sa référence (ou plus précisément la grille qui permet de l'interpréter) est supprimée.

Naturellement, les informaticiens ont mis en place des procédures temporaires pour préserver le temps[3] et réfléchissent à une réorganisation de la gestion du projet pour que cela ne soit pas reproductible. Mais le problème initial demeure, à savoir que de plus en plus des actes juridiques aberrants attentent non seulement aux libertés fondamentales, mais mettent aussi en danger notre vie quotidienne.

Que des avocats agissant au nom d'une société aient pu mettre à genoux le temps, simplement en ayant une mauvaise connaissance du sujet qu'ils traitent et en abusant d'une législation créé pour protéger la rente culturelle des grands groupes internationaux, est inacceptable.

Solution(s)

Une solution serait de faire avancer les réformes sur le droit d'auteur, la protection des œuvres, et de poursuivre la législation sur les droits et devoir des hébergeurs internet afin que cette situation ne puisse pas se reproduire. C'est le but des lois DADVSI, HADOPI et LCEN. Malheureusement cette approche est vouée à l'échec, de part la nature de la technique du numérique et de celle du travail législatif. Il va vraiment falloir que le législateur accepte le fait qu'il ne peut pas simplement « réguler internet ».

Plus prosaïquement, une solution pratique serait de supprimer la propriété intellectuelle sur les œuvres de l'esprit, les logiciels, et les brevets. Pan. Ah oui, c'est vrai : cela ne plairait pas à Vivendi Universal. Donc à la place on préfère conserver une loi qui permet de casser tous les appareils informatiques avec une simple lettre de 5 pages envoyée de l'autre côté de l'océan par une personne sur laquelle on n'a aucun contrôle.

Notes

[1] Si vous êtes directement concerné et que vous n'êtes pas au courant de cette histoire, posez-vous sérieusement la question de votre qualification… vraiment.

[2] Imaginez que vos dispositifs informatiques dépendent du bon vouloir politique d'un pays tiers ; vous apprécieriez ? Je ne pense pas ; donc c'est très bien que la politique reste en dehors du projet.

[3] Ah, l'informaticien, ce héros des temps modernes. Il passe sa vie à Sauver le Monde, et le grand public ne le sait jamais.

dimanche 24 avril 2011

TraceFS, grep, et plus si affinités

Concept

L'idée est de présenter une trace modélisée sous forme d'arborescence de fichiers, via FUSE. Les accès se font par une combinaison d'utilisateur, de modèle, de trace, et d'observé. On peut alors avoir des choses comme /utilisateur/utilisateur4/modèles/modèle5/trace/trace3/observé/observé6.

L'intérêt est ensuite d'extraire les données avec des outils standards POSIX, pour consulter et éventuellement modifier les traces. Le format des fichiers peut être de différente sorte, selon l'option de montage du système de fichier (flat, json, n3, etc)

Exemple

Pour l'utilisateur « Damien », dans la trace « Exercice2 » de « WeeChat », savoir combien d'observés sont de type frappeClavier. On constate que la trace accédée directement par son nom via le sujet de la trace : le modèle est passé sous silence car ces informations suffisent à discriminer la trace dans la base de traces.

$ grep -irc "type=frappeClavier" /utilisateur/Damien/trace/Exercice2/ | wc -l
3151

[1]

L'avantage est de pouvoir directement interroger le SGBT avec des outils standards. Pour l'utilisateur, cela signifie :

  • une grande simplicité : pas besoin de concevoir de scripts python, d'apprendre des API ou de déployer du code sur le SGBT. Toutes les opérations se font avec des outils standards UNIX, voir POSIX, ce qui signifie une prise en main immédiate.
  • un important gain de temps : accéder au contenu d'un observé est immédiat, et ne nécessite que la lecture d'un fichier

Durant la phase de travail sur la conception d'un modèle de trace, ou l'instrumentation d'un outil, je vois un intérêt à ce genre d'approche.

Note

[1] les geeks auront repéré la blague dans la commande :)

jeudi 19 août 2010

Les chercheurs, la voiture et le plot : une réflexion sur l'usage de la force brute

Au LIRIS, nous n'hésitons à pas donner de notre personne pour résoudre les problèmes. Surtout quand il ne sont pas du domaine de nos spécialités. Laissez-moi vous raconter une histoire.

L'histoire

Il était une fois, un groupe de chercheurs qui sortaient de leur laboratoire afin de rentrer chez-eux.

Chemin faisant, ils se firent héler par une splendide demoiselle aux doux yeux maquillés tel le dieu Ra. La jeune fille était bien en peine car sa voiture, suite à une mauvaise manœuvre, se trouvait perchée sur un plot de béton.

Voiture coincée

Les chercheurs étaient emplis de bonne volonté et s’approchèrent afin d’examiner cette curiosité. Ils se mirent à tourner autour de la voiture, à palper des éléments, à poser des hypothèses et à estimer les différents paramètres.

Leur conclusion fut sans appel : oui, cette voiture était effectivement bloquée sur le plot en béton, et le dégagement allait être une opération délicate car son dessous commençait à être endommagé.

Voiture coincée, vue de dessous avant, protection endommagée
Voiture coincée, vue de dessous avant, protection endommagée

Une fois ce constat établit, restait aux chercheurs à proposer et à mettre en œuvre une solution. En effet, la demoiselle en détresse n'avait pas fait appel à eux pour lui apprendre ce qu'elle savait déjà (à savoir que sa voiture était coincée sur un plot de béton), mais bien pour y apporter une réponse.

Comme nos chercheurs étaient emplis de bonne volonté et se sentaient d'humeur virile, ils affirmèrent vouloir relever ce défi. Mais comment faire ? Deux courants de pensée apparurent.

Il y avait d'une part des chercheurs, emportés dans un élan idéaliste, qui songeaient à fournir des appuis supplémentaires à la voiture afin de lui permettre de se mouvoir de nouveau; et donc de se dégager par elle-même. En langage courant on appelle cette technique « mettre une rampe sous les roues ».

Et d'autre part, des chercheurs (sans doute pressés de rentrer chez eux vu l'heure déjà tardive; qui pourrait leur en vouloir ?) préféraient dégager la voiture à la main en la portant.

En personnes civilisées, les chercheurs se sont mis à débattre du pour et du contre de ces deux approches. Pendant que la demoiselle en détresse commençait à désespérer de voir son problème résolu (surtout que, apparemment, la voiture n'était pas à elle…).

Ne pouvant arbitrer, mais restant toujours bons collègues, les chercheurs établirent le compromis de réaliser les deux solutions.

Le premier petit groupe de chercheurs s'en allât emprunter sur un chantier voisins des matériaux de construction : parpaings, planches épaisses, cales… ils étaient certains d'y trouver les ressources nécessaires à leur entreprise.

Pendant ce temps, hésitant sur la conduite à tenir durant l'expédition du premier groupe, le second groupe de chercheurs rassurait la demoiselle en détresse. Se faisant, les chercheurs examinaient aussi la voiture; cherchant qui des points de levage, qui estimant l'effort à fournir pour lever et porter la voiture, etc.

Voiture libérée

Finalement, n'y tenant plus et ne voyant toujours pas revenir le premier groupe, les chercheurs du second se rassemblèrent autour de la voiture, la levèrent et la portèrent au delà du plot bétonné.

Folle de bonheur, la demoiselle remercia ses sauveurs et s'en allât rejoindre son prince charmant. Ne voyant toujours pas revenir ceux du premier le groupe, les chercheurs se dispersèrent pour rentrer chez eux.

Nul ne sut jamais ce qu'il advint des autres chercheurs partis en quête de matériaux.

Conclusion

Il ne faut pas sous-estimer la capacité de la force brute à résoudre un problème complexe ou sensible.


Discussion

Régulièrement dénigrée dans le monde de la recherche où elle peut être qualifiée d' « inélégante » et de « simpliste », la force brute n'est pas pour autant dénuée de qualités.

En effet, utilisée correctement, elle permet de répondre à un besoin avec des coûts modérés et une mise en œuvre rapide.

Par exemple, supposons que nous aillons à examiner 30000 heures de vidéo provenant de caméras de surveillance pour en relever les passages d'un personne. Les images, qui proviennent d'appareils de qualité moyenne, sont régulièrement floues ou bruitées.

Quelle est la solution la plus rentable ? Concevoir et développer un logiciel d'analyse d'image avec détection de formes et reconnaissance de visages, ou d'embaucher 100 chinois 10 heures par jour durant 30 jours ?

Dans le premier cas, il faut recruter des experts, des ingénieurs et des développeurs dans de nombreuses disciplines : génie logiciel, analyse de signal, traitement de données temporelles, etc. Cela coûte cher et l'estimation du temps nécessaire à la mise en œuvre est imprécise.

Dans le second cas, avec 100 chinois payés $5 par jour durant 30 jours, le coût sera de $15000 et le travail aisé à planifier.

Certes, on peut avancer que le développement du logiciel de reconnaissance est un investissement et permet donc de diminuer le coût unitaire à la longue. Mais en contrepartie, il est moins adaptable que les humains à qui on pourra demander de rechercher dans les images une voiture, une personne portant une valise précise, etc.

Il est également important d'évaluer le coût de maintenance : revient-il plus cher de remplacer un élément déficient (pour cause de maladie ou de casse) d'un système base sur la force brute (tel un ouvrier chinois ou encore un ordinateur basic), ou bien de remplacer un élément d'un système sophistiqué (tel un expert international ou un supercalculateur intégré) ?

Malgré tout, il ne faut pas oublier que l’apparente simplicité d'une solution à base de force brute est illusoire. Cette approche demande des investissements en coordination et en gestion des nombreux éléments : il est loin d'être évident d'interconnecter des milliers d'ordinateurs, et lorsqu'il s'agit de travailleurs humains le support devient une tâche à part entière (rotation d'équipes, restauration, commodités, etc.)

Le choix de la stratégie d'approche intervient tôt dans le cycle de résolution de problème; on constate qu'il peut avoir un impact significatif sur le reste du projet. il est donc important d'évoquer la question suffisamment tôt, par exemple durant la phase d'analyse, afin de ne pas se retrouver piéger.

mercredi 16 décembre 2009

Avancement sur les outils de la trace

Hier est un jour à marquer d'un parpaing blanc : j'ai mis en place la première interconnexion de 3 outils différents qui manipulent des éléments de trace : le client IRC weechat, le préparateur de traces de weechat, et le ktbs. Plus précisément, la séquence réalisée est WeeChat → préparateur de trace → ktbs.

  • WeeChat : il s'agit du client IRC que j'ai instrumenté pour sortir des proto-observés représentant l'activité de l'utilisateur dans celui-ci.
  • préparateur de trace : un agent logiciel spécifique à WeeChat, développé par moi, en charge de :
    • construire des observés à partir des proto-observés
    • assurer l'interconnexion avec le SGBT
    • initialiser le SGBT pour permettre son utilisation (définition de l'utilisateur, du modèle, de la trace, etc)
  • ktbs : l'implémentation du SGBT réalisée par Pierre-Antoine

Ça n'a l'air de rien comme cela, mais tous ceux qui se sont concrètement frottés à la conception complète de modèles, à la création technique de traces, et au KTBS vous diront que c'est limite un exploit :)

Bon, maintenant pour être honnête, je dois dire aussi qu'il y a des warnings dans tous les sens, que ça crash aléatoirement et que c'est vraiment pas évident de tout faire tenir ensemble. Mais le résultat est qu'au final il est possible de demander au KTBS de recracher une trace qu'il a précédemment reçu.

Dans tous les cas, c'est encore loin d'être utilisable, même pour faire des petits essais. Le travail d'ingénierie à réaliser est LOURD, et le code pas réutilisable car spécifique à un outil. mais ça marche \o/

mercredi 23 septembre 2009

Interconnexion application flash ↔ KTBS

Bonne nouvelle, les interconnexions sont en train de se mettre en place entre le KTBS et différents prototypes. Par contre, il reste du boulot.

Enfin bon, ça commence à tourner, c'est le principal. Voici un extrait de code en ActionScript montrant comment faire un aller-retour entre une application Flash et le KTBS. Notez la création simple de la liaison pour le service web via le HTTPService(). En revanche, ne me demandez pas (encore) comment on fait si la connexion timeout, saute, se bouche ou autre. Il est également possible d'utiliser directement des sockets, ce qui est pratique pour affiner les choses à la main.

Sérieusement, ce langage est immonde. Ça a la lourdeur du javascript, et la grammaire a été conçue par un polonais shooté à la vodka : ça ressemble presque à un langage normal, sauf quand ils se sont amusé à permuter l'ordre des éléments sans aucune raison valable (genre variable:type ← franchement, faut être malade pour inventer ça...). C'est supposé être un langage de haut niveau, userfriendly et tout, mais on se tape les contraintes héritées des années 70 (marqueur de fin de ligne, typage fort, etc). Et surtout ils ont tout pété entre les versions 2 et 3 du langage. Sans compter que le compilateur (en java) a le dynamisme d'une vache salers explosée au Lexomil.

Dernier détail : sur le papier, l'eventListener fonctionne, mais en pratique il ne me donne rien; je soupçonne fortement un tripatouillage interne des données, genre « bouge pas, je vais te mettre ça en forme et nettoyer ce qui ne sert pas ». Ben tiens...

// l'objet décrivant le SGBT
private var _sgbt :HTTPService;


/*
 * constructeur de KTBS
 */
public function SGBT() :void {
// création d'un service web sur le KTBS de PA
	_sgbt = new HTTPService();
	_sgbt.url = "http://ip6-localhost:8001/";
	_sgbt.method = "GET";
	_sgbt.contentType = "application/rdf+xml";
// reniflage de la réponse du KTBS, avec appel à reponse() en lui passant les données retournées
	_sgbt.addEventListener(ResultEvent.RESULT, reponse);
	_sgbt.send();
}


/*
 * traite les données reçues du KTBS
 * retourne : rien
 * mesData est l'événement provenant du listener sur requête du KTBS
*/
public function reponse(mesData :ResultEvent) :void {
	_sgbt.removeEventListener(ResultEvent.RESULT, reponse);
// trace() est une primitive de déboguage écrivant sur la sortie standard
	trace(mesData.result.toString());
}

lundi 7 septembre 2009

Génération automatique du modèle de trace d'une application instrumentée

Le problème

Maintenir la conception du modèle de trace d'une application de la conception de l'application n'a pour moi pas de sens : on perd du temps à passer de l'un à l'autre, on s'embrouille et c'est une approche préhistorique (ou du moins datant du COBOL :)

On pourrait se dire que disposer d'un modèle de l'application ne présente pas nécessairement un intérêt quand on cherche à obtenir une trace des interactions d'un utilisateur, mais pour moi c'est sauter une étape.

En effet, depuis de nombreux mois plusieurs personnes de l'équipe SILEX travaillent sur des modèles d'interactions. Au delà des problèmes concrets lié à l'expression de modèles conformes au métamodèle, il se pourrait qu'une des choses qui nous freine soit de vouloir réaliser tout de suite un grand pas : on ne sait pas décrire le comportement d'une application, alors qu'on veut décrire le comportement de l'utilisateur dans cette application.

La solution (possible ?)

Plus j'y pense, et plus je me dis que la solution passe peut-être par une génération automatique des modèles de l'application. Le principe serait alors de générer le(s) modèle(s) de l'application à la compilation, sur le même principe que la documentation des API tel javadoc ou doxygen.

On peut songer à quelque chose de similaire au javadoc : avec des marqueurs bien placés dans le code, on génère à la compilation des modèles correspondant à des éléments d'interface.

Du coup, on permet au développeur de structurer les modèles de l'application, tout en permettant à l'utilisateur de concevoir des modèles supplémentaire.

Conceptuellement

idée clé : les API sont un modèle de l'application orienté développeur; le modèle de trace d'interactions est un modèle de l'application orienté utilisateur.

Cette approche serait utilisée, a priori, uniquement pour les applications instrumentées directement dans le code. Éventuellement, peut-être aussi pour les enrichissements d'application à base de plugins, mais il faudrait que j'y réfléchisse.

En pratique

Pour réaliser la génération de modèle d'application, ces questions pratiques se posent : sur quelles fonctions placer les marqueurs de génération d'observés ? Callback/méthode associés aux widgets ? D'une façon générale, très probablement sur les fonctions les plus proches de l'utilisateur, donc au niveau des E/S. L'idée est de ne pas ajouter de code, juste des commentaires contenant les marqueurs.

On commence par définir globalement les propriété communes : références au métamodèle, à l'extension temporelle, etc. On peut songer par exemple à un mécanisme de macro ou de variables (je l'appellerais ici « en-tête 1 »

=define "en-tête 1"
@prefix : <http://liris.cnrs.fr/silex/ns/ktbs/>.
@prefix mod: <>.
@prefix xsd: <TODO> .

<> a :TraceModel ;
	:hasTemporalDomain :seconds .

Puis, dans le code de l'application on insère les marqueurs pour la génération du modèle

/*
 * =include "en-tête 1"
 * =type presseTouche
 * =description "décrit la frappe d'une touche dans la zone de saisie"
 * =string "versionDeWeeChat"
 * =string "monPseudo"
 * =string "nomDuCanal"
 */ 
LaFonctionGérantLesFrappesClavierDeLutilisateur(...) {
	...
}

Et là, c'est le drame car il faut exprimer des choses comme comme le fragment ci-dessous.

>:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;%%%
	xsd:pattern "(#|&)[a-zA-Z0-9]{,63}"
]

Mais l'idée reste la même : pour moi, les informations permettant la génération du modèle doivent être notées sous forme réduite, juste à côté du code, et sans gêner les développeurs.

Le modèle généré :

@prefix : <http://liris.cnrs.fr/silex/ns/ktbs/>.
@prefix mod: <>.
@prefix xsd: <TODO> .

<> a :TraceModel ;
	:hasTemporalDomain :seconds .


mod:presseTouche a :ObserType .


mod:versionDeWeeChat a :Attribute ;
	:aDomain mod:presseTouche ;
	:aRange xsd:string ;
.

mod:monPseudo a :Attribute ;
	:aDomain mod:presseTouche ;
	:aRange xsd:string ;
.

mod:nomDuCanal a :Attribute ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
		owl:onDatatype xsd:string ;
		xsd:pattern "(#|&)[a-zA-Z0-9]{,63}"
	] 
.

mod:nomDuServeur a :Attribute ;
	rdfs:label "Nom du Serveur"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "(IPv4|IPv6|hostname)"
	]
.

mod:typeDeTampon a :Attribute ;
	rdfs:label "Type de tampon"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "[0-2]"
	]
.

mod:caractère a :Attribute ;
	rdfs:label "Caractère frappé"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "(\*?|STRING)"
	]
.

mod:zoneDeSaisieAvantCaractère a :Attribute ;
	rdfs:label "Contenu de la zonne de saisie avant la frappe clavier"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern ".*"
	]
.

mod:zoneDeSaisieAprèsCaractère a :Attribute ;
	rdfs:label "Contenu de la zonne de saisie après la frappe clavier"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern ".*"
	]
.

mod:drapeauAway a :Attribute ;
	rdfs:label "Status de présence"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "(0|1)"
	] ## ?? vérifier dans la spec de OWL 2
.

mod:contenuDeLaZoneDeSaisie a :Attribute ;
	rdfs:label "Contenu de la zone de saisie"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern ".*"
	]
.

mod:contenuDuMasqueDeCouleurDeLaZoneDeSaisie a :Attribute ;
	rdfs:label "Masque de la zone de saisie"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern ".*"
	]
.

mod:positionDuCurseurDansLaZoneDeSaisie a :Attribute ;
	rdfs:label "Position du curseur dans la zone de saisie"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "[0-9]*"
	]
.

jeudi 30 juillet 2009

Pourquoi je ne crois pas (encore) en la trace modélisée

Non, non, ne hurlez pas; je vous vois venir avec vos mais qu'est-ce qu'il va encore nous inventer cette fois-ci ? :)

Lisez, vous allez voir, ça va vous intéresser.

Avant-propos

Je travaille depuis maintenant un bon moment à mettre en place une partie de nos idées sur les traces, concernant la visualisation d'activité (individuelle ou collaborative, a/synchrone, ici on s'en fout). Architecture, conception de modèles, instrumentation d'application, couche réseau, formats de données, parsers, etc; vous l'avez compris, tout passe entre mes mains excepté le SGBT qui est pour moi une boîte noire. Si vous pouvez imaginer quelque chose relatif aux traces (RàPC excepté), alors je me suis certainement penché dessus à un moment durant ces six derniers mois.

Je vous présente ici un retour sur l'expérience que j'ai développé, à base de réflexions personnelles. Le constat est plutôt mitigé, je vous préviens d'avance. Rien de dramatique, mais il faudra en tenir compte pour la suite de nos travaux car ça a des conséquences importantes. Je vais essayer de faire un découpage propre, mais vous allez voir que tout est lié.

Ma réflexion est orientée sur le transfert vers l'entreprise (non, ce n'est pas un gros mot) de nos travaux de recherche. C'est à dire : « qu'est-ce qu'il faut prendre en compte lorsqu'on va essayer de vendre la trace modélisée à un industriel ».

La conception de modèle

La première étape de l'enrichissement d'une situation informatique par les traces (sous-entendu, après tout le blabla d'analyse) est la conception d'un modèle de traces de logiciel(s). Cela :

Demande des compétences très spécialisées

Soyons réalistes, comprendre la théorie de la trace modélisée et être capable d'expliciter des interactions dans son formalisme n'est pas à la portée de tout le monde. Non pas que cela soit particulièrement complexe, mais cela exige un certain nombre de connaissances et de compétences qui ne se trouvent pas partout.

Que ce soit par une méthode ascendante ou descendante, concevoir des modèles de trace d'applications ne peut être fait que par un petit nombre de personnes. Or, ce qui est rare est cher. Il va donc falloir convaincre l'entreprise de réaliser cet investissement. Cela peut passer par une mission d'un expert extérieur, la formation d'une personne déjà en place, un partenariat avec une structure compétente, etc. Plusieurs possibilités existent, mais toutes ont un coût qui n'est pas négligeable.

Nécessite beaucoup de temps

Un logiciel, même très simple, est riche en possibilités d'interactions. On peut retenir l'utilisation de menus, de boutons, de paramètres, de zones de saisie, de fonctions, etc, ainsi que des opérations plus globales impliquant les périphériques d'entrée et de sortie.

Au final, on se retrouve à manipuler un très grand nombre d'observés et de relations, ce qui nécessite plusieurs jours semaines de travail. La richesse en observés étant exponentielle par rapport à la complexité d'un logiciel, essayez de visualiser ce à quoi pourrait ressembler le modèle de trace d'OpenOffice. Oui, c'est plus que gros : c'est énorme. Et on ne peut pas se permettre de laisser de côté certaines parties du modèle car cela impliquerait de ne pas être capable de représenter correctement les interactions de l'utilisateur sur ce logiciel.

L'entreprise ayant besoin de tracer une activité, un environnement ou que sais-je encore, va devoir y passer du temps (qui est aussi de l'argent, comme nous le rappel le célèbre adage). Ce temps sera pris au dépend d'autres activités, peut-être plus facilement et rapidement rentables.

Comprend aussi la conception des règles de transformations usuelles

Tout comme sans maîtrise, la puissance n'est rien, des traces qu'on ne peut pas manipuler sont tout de suite moins intéressantes. La conception de jeux de règles de transformations adaptées aux modèles de traces est un des à-côté du travail conceptuel de la trace.

En effet, on ne peut pas simplement donner un modèle de trace à une entreprise en lui disant « voilà, tu as ton modèle, à toi de te débrouiller pour faire ce que tu veux avec ». Il faut donc en parallèle du modèle construire les règles de transformations qui vont les utiliser, afin d'obtenir un résultat final qui corresponde aux attentes de l'entreprise. L'entreprise pourra certes produire en interne de nouvelles règles de transformations (par une tactique de copie/adaptation), mais il faudra lui préparer le terrain. Et qui est-ce qui va se taper le travail ? Gagné, c'est l'expert qui s'occupe déjà du modèle. Cela augmente sensiblement sa charge de travail, et donc le coût pour l'entreprise.

Instrumentation des logiciels

Selon le logiciel à instrumenter, le travail technique pour réaliser la collecte d'observés varie grandement. J'ai identifié 3 catégories d'instrumentation :

  • édition en profondeur du code source : méthode qui nécessite d'avoir accès au code source du logiciel, et d'être en mesure d'y apporter des modifications;
  • création de greffons présentant des interfaces pour interroger le contenu de variables d'état : ici, on ajoute des fonctionnalités à l'application en s'appuyant sur ses API. On est limité par ce que propose l'application en terme d'accès aux ressources internes.
  • création de préparateurs de traces qui récupèrent des données exportées par l'application pour produire des observés : cette approche consiste à récupérer des informations sorties de l'application via ses méthodes standard (par exemple, flux RSS ou AppleEvent). Cette méthode apporte le découpage le plus fort dans le tandem application/traçage, et est limitée par l'application elle-même.

Selon les applications à instrumenter et les méthodes utilisées, le coût de l'adaptation logicielle varie énormément. Malheureusement, il n'est pas possible d'identifier un petit nombre de critères précis permettant de quantifier simplement ce coût. C'est uniquement en prenant en compte une combinaison de nombreux facteurs qu'on peut le déterminer. À titre d'idée, on peut citer sans s'y restreindre :

  • la complexité du travail;
  • la durée du travail;
  • le langage de programmation (allez trouver quelqu'un qui fait encore du COBOL, tiens :)
  • la documentation disponibles (humain, référentiel de développement, etc);
  • l'urgence;
  • etc.

Il y a également les coûts liés; par exemple, les structurels : achat d'un serveur pour le SGBT, mise à jour des matériels, adaptation de l'architecture réseau...

Les cycles de vie logiciel dans environnements tracés

Un logiciel peut être vu comme quelque chose de « vivant », évoluant au fur et à mesure des versions. Ces évolutions sont nécessaires pour de nombreuses raisons : changement dans l'environnement d'accueil (le système d'exploitation), sécurité, nouvelles fonctionnalités, etc.

Tout naturellement, il faut que les éléments du traçage accompagnent ces évolutions. Tout s'enchaînent très rapidement de façon implacable :

  1. modifier le logiciel tracé (peut) oblige(r) à modifier la collecte
  2. modifier le logiciel tracé oblige (pas moyen d'y échapper, là) à modifier le modèle de traces
  3. modifier le modèle de traces oblige à modifier les transformations de traces (et oui...)
  4. modifier les transformations de traces impacte sur la visualisation des traces (j'y reviendrais plus tard)

On se rend compte alors que la mise à jour est coûteuse car il faut de nouveau faire appel à notre expert. Vous souvenez de lui, celui de la 1e étape, qui avait conçu les modèles ? Et bien il va falloir retourner le voir pour lui demander de se pencher sur les modifications. Ceci dit, ça tombe bien car il pourra tout traiter d'un seul coup : l'évolution des modèles et celle des transformations. Et si en plus derrière il peut assurer la formation ça ne sera pas perdu.

Le plus problématique est qu'il faut répéter ce cycle à chaque nouvelle version du logiciel. C'est réellement un surcoût, car la rentabilité n'est pas évidente à dégager (comptablement parlant).

Mentalement, insérez ici un joli schéma de traces complet d'une application, montrant côte à côte les modèles de traces pour la version N et la version N+1. Imaginez de gros, gros (mais alors gros), graphes avec des nœuds et des arcs dans tous les sens, qui seraient différents de seulement quelques détails : observés en plus ou en moins, déplacement de relations, changement d'attributs, etc.

Je mettrais les schémas quand je les aurais fini, le but est ici de vous faire prendre conscience du volume de travail que ça représente.

Pratiques des utilisateurs liées aux traces

En ce qui concerne l'utilisateur final, c'est plus simple pour lui. Une évolution de son environnement tracé se traduit non seulement par une modification de sa pratique métier, mais également de sa pratique réflexive via les traces. Ben oui, vous ne croyez quand même pas qu'au final rien ne change ? Et comme nous le savons, tout ce qui change les habitudes de l'utilisateur le fait râler (sauf si c'est Génial, mais ça seul Apple arrive à le faire :)

De petites modifications dans un logiciel peuvent avoir de grandes répercutions sur le modèle de trace, et donc sur la visualisation interactive de la trace par l'utilisateur. Il va donc lui falloir un temps d'adaptation (ce qui influera sur sa productivité), voir même une formation.

Également, les changements dans les traces et modèles pourront se propager à d'autres environnements, tracés ou non. C'est le cas lors de la documentarisation de traces en vue de générer des productions (textes, hypermédia, etc.) Même si ces outils ne sont pas tracés, ils sont impactés par les changements sur les données d'entré.

Que retenir au final ?

On peut dire qu'instrumenter un environnement pour lui faire générer des traces est long, pas toujours simple, et n'est pas nécessairement faisable de façon clairement rentable.

Les problèmes apparaissent à tous les niveaux : conceptuel (modèles), technique (instrumentation) et humain (usage). Les principaux étant le coût (je crois l'avoir suffisamment répété :) de la mise en œuvre de la trace dans un système existant, et les compétences spécialisées requises dans chacune des étapes de la réalisation.

Convaincre un industriel d'investir dans la trace est alors réellement un problème, car les gains à dégager sont difficilement calculables, et la mise initiale est élevée.

Au final, pour moi la théorie de la trace est attirante sur le papier, mais les difficultés liées à la réalisation sont vraiment rebutantes.

Pistes envisageables

Tout n'est pas perdu ! Maintenant que nous avons regardé le problème droit dans les yeux, on peut louvoyer en évitant ce qui justement nous embête.

Ainsi, on peut songer à cibler en priorité les systèmes figés, qui n'évoluent pas ou très peu :

  • machine-outil : une chaîne de production change rarement, car son utilisation est planifiée en amont. Du coup, pas besoin non plus de faire évoluer les trucs-de-la-traces \o/
  • systèmes critiques : les outils comme ceux du contrôle aérien n'ont pas le même cycle de vie que les logiciels grand public; on ne passe pas son temps à les mettre à jour. Il sont conçus pour durer, et c'est au contraire les autres systèmes qui s'adaptent pour interagir avec eux. En gros, une fois le traçage dedans, il n'en bouge plus.
  • logiciels arrivés à maturité; ils peuvent être complexes (Lotus Notes) ou très simples (calepin de Windows). De par leur nature, rôle ou histoire, certains logiciels sont intouchables; on se contente au plus de les recompiler, mais en veillant à ne rien changer afin de ne pas provoquer d'effets de bord (comme par exemple un changement de modèle de trace).

Une autre approche est de se poser la question de savoir qui a suffisamment d'argent à dépenser pour se lancer dans un projet pareil, sans que le responsable risque de se faire virer après la réception de la facture par le service compta :

  • les grands comptes : la Poste, EDF (eh, ça tombe bien :), etc;
  • la fonction publique : quand l'administration investie, elle ne le fait pas à moitié; souvenons-nous du « Plan informatique pour tous »;
  • les Décideurs Pressés qui imposent contre l'avis de leurs DSI des solutions qu'ils jugent intéressantes. Avec un joli PowerPoint®™©, on arrive à vendre des glaçons au Pôle Nord.

Vous l'avez compris, j'exclus tout ce qui est grand public dans les cibles potentielles. Il y a éventuellement le monde du Libre qui pourrait mettre en place et maintenir des utilisations de traces modélisées, mais il faudrait vraiment que ça soit pertinent.

mercredi 10 juin 2009

Appel à commentaires sur les modèles de trace

Avant propos

Il y a deux abréviations à connaitre.

i18n (internationalization) internationalisation

Les adaptations à faire sur les formats de données, selon les pays. Par exemple, comment on exprime une date (JJ/MM/AA, MM/DD/AA, etc), une monnaie ($123, 123€), un nombre (123.456 ou 123,456), etc. C'est un travail technique qui demande à faire abstraction du contenu pour en décrire sa structure.

CF l18n

l10n (localization) régionalisation

Il s'agit de la traduction à proprement parler.

WP :

La régionalisation de logiciel concerne le processus de traduction de l'interface utilisateur d'un logiciel d'une langue vers une autre et en l'adaptant à la culture locale. On utilise parfois le terme localisation, qui est une transposition du mot anglais localization (faux ami). On écrit parfois l10n car le mot localization est composé de dix lettres encadrées par un l et un n.

Avant qu'un logiciel ne soit régionalisé, il faut au préalable qu'il ait été internationalisé, c’est-à-dire qu'il ait été écrit pour pouvoir être traduit dans différentes langues et cultures.

CF l10n

Discussion sur les modèles

Pour construire l'interface de l'outil générique de visualisation interactive de trace (OGVIT), il faut que chaque attribut ait un nom compréhensible pour l'utilisateur. Ce qui veut dire qu'au couple attribut+valeur (par exemple, ktbs:hasTime et 1244638257), il faut ajouter un 3e élément qui est le « nom humain » (mercredi 10 juin 2009, 14:50:57)

De plus , ce nom humain doit pouvoir être internationalisé (et localisé), car tout le monde n'utilise pas la même langue. Ce qui veut dire qu'un observé, au final, doit autant être compréhensible par la machine que par l'humain. Si l'humain sait vaguement s'adapter, la machine elle a besoin d'un formalisme explicite.

Il existe plusieurs endroits où ajouter ces élément de i18n et de l10n :

Dans l'observé lui-même

  • avantage : l'information est immédiatement présente, on peut la traiter directement
  • inconvénients :
    • ça prend de la place, on répète l'information autant de fois qu'on a d'observés.
    • pour gérer plusieurs langues, il faudra ajouter autant d'éléments de traduction; c'est du gaspillage.

Dans le modèle de trace

  • avantage : c'est définit une fois pour toute; on économise de la place et du temps
  • inconvénients :
    • on se retrouve à trimbaler dans le modèles des informations dont on n'a pas besoin. Par exemple, moi je n'ai pas besoin de pouvoir exprimer mes dates en japonais.
    • ajouter une langue revient à reprendre le modèle, ce qui n'est pas toujours évident à faire car celui-ci n'est pas forcément modifiable. Par exemple, il peut être intégré dans une application dont on n'a pas les sources.

Dans un document à côté du modèle

  • avantages :
    • on peut modifier et compléter les traductions et formats sans toucher au modèle.
    • le modèle ne contient que la définition de la trace, le reste étant dans un document associé.
  • inconvénients :
    • quand on veut manipuler un modèle, il faut alors manipuler deux fichiers pour avoir les littéraux. Pas pratique.
    • ça complique le schmilblick.

Reste à décider. Vos avis sur la question ?

Exemple concret

Je souhaite visualiser la trace de ma (« Damien_traces ») frappe clavier dans weechat, mon client IRC tracé. La trace correspondant à l'envoi du message « bonjour » sur le canal #LIRIS de Freenode est la suivante :

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix ktbs: <http://liris.cnrs.fr/~ithaca/ns/ktbs/0.1/> .
@prefix : <http://example.com/trace-model/> .

[ a :presseTouche;
:versionDeWeechat "0.2.6.1";
:monPseudo "Damien_traces";
:nomDuCanal "#LIRIS";
:nomDuServeur "freenode";
:typeDeTampon (0=standard, 1=DCC, 2=données IRC brutes) "0";
:caractère "*b";
:zoneDeSaisieAvantCaractère "";
:zoneDeSaisieAprèsCaractère "b";
:drapeauAway "0";
:contenuDeLaZoneDeSaisie "b";
:contenuDuMasqueDeCouleurDeLaZoneDeSaisie " ";
:positionDuCurseurDansLaZoneDeSaisie "1";
ktbs:hasBegin "1244635383";
ktbs:hasEnd "1244635383";
ktbs:hasTrace <> ;
].

[ a :presseTouche;
:versionDeWeechat "0.2.6.1";
:monPseudo "Damien_traces";
:nomDuCanal "#LIRIS";
:nomDuServeur "freenode";
:typeDeTampon (0=standard, 1=DCC, 2=données IRC brutes) "0";
:caractère "*o";
:zoneDeSaisieAvantCaractère "b";
:zoneDeSaisieAprèsCaractère "bo";
:drapeauAway "0";
:contenuDeLaZoneDeSaisie "bo";
:contenuDuMasqueDeCouleurDeLaZoneDeSaisie "  ";
:positionDuCurseurDansLaZoneDeSaisie "2";
ktbs:hasBegin "1244635383";
ktbs:hasEnd "1244635383";
ktbs:hasTrace <> ;
].

[ a :presseTouche;
:versionDeWeechat "0.2.6.1";
:monPseudo "Damien_traces";
:nomDuCanal "#LIRIS";
:nomDuServeur "freenode";
:typeDeTampon (0=standard, 1=DCC, 2=données IRC brutes) "0";
:caractère "*n";
:zoneDeSaisieAvantCaractère "bo";
:zoneDeSaisieAprèsCaractère "bon";
:drapeauAway "0";
:contenuDeLaZoneDeSaisie "bon";
:contenuDuMasqueDeCouleurDeLaZoneDeSaisie "   ";
:positionDuCurseurDansLaZoneDeSaisie "3";
ktbs:hasBegin "1244635383";
ktbs:hasEnd "1244635383";
ktbs:hasTrace <> ;
].

[ a :presseTouche;
:versionDeWeechat "0.2.6.1";
:monPseudo "Damien_traces";
:nomDuCanal "#LIRIS";
:nomDuServeur "freenode";
:typeDeTampon (0=standard, 1=DCC, 2=données IRC brutes) "0";
:caractère "*j";
:zoneDeSaisieAvantCaractère "bon";
:zoneDeSaisieAprèsCaractère "bonj";
:drapeauAway "0";
:contenuDeLaZoneDeSaisie "bonj";
:contenuDuMasqueDeCouleurDeLaZoneDeSaisie "    ";
:positionDuCurseurDansLaZoneDeSaisie "4";
ktbs:hasBegin "1244635384";
ktbs:hasEnd "1244635384";
ktbs:hasTrace <> ;
].

[ a :presseTouche;
:versionDeWeechat "0.2.6.1";
:monPseudo "Damien_traces";
:nomDuCanal "#LIRIS";
:nomDuServeur "freenode";
:typeDeTampon (0=standard, 1=DCC, 2=données IRC brutes) "0";
:caractère "*o";
:zoneDeSaisieAvantCaractère "bonj";
:zoneDeSaisieAprèsCaractère "bonjo";
:drapeauAway "0";
:contenuDeLaZoneDeSaisie "bonjo";
:contenuDuMasqueDeCouleurDeLaZoneDeSaisie "     ";
:positionDuCurseurDansLaZoneDeSaisie "5";
ktbs:hasBegin "1244635384";
ktbs:hasEnd "1244635384";
ktbs:hasTrace <> ;
].

[ a :presseTouche;
:versionDeWeechat "0.2.6.1";
:monPseudo "Damien_traces";
:nomDuCanal "#LIRIS";
:nomDuServeur "freenode";
:typeDeTampon (0=standard, 1=DCC, 2=données IRC brutes) "0";
:caractère "*u";
:zoneDeSaisieAvantCaractère "bonjo";
:zoneDeSaisieAprèsCaractère "bonjou";
:drapeauAway "0";
:contenuDeLaZoneDeSaisie "bonjou";
:contenuDuMasqueDeCouleurDeLaZoneDeSaisie "      ";
:positionDuCurseurDansLaZoneDeSaisie "6";
ktbs:hasBegin "1244635385";
ktbs:hasEnd "1244635385";
ktbs:hasTrace <> ;
].

[ a :presseTouche;
:versionDeWeechat "0.2.6.1";
:monPseudo "Damien_traces";
:nomDuCanal "#LIRIS";
:nomDuServeur "freenode";
:typeDeTampon (0=standard, 1=DCC, 2=données IRC brutes) "0";
:caractère "*r";
:zoneDeSaisieAvantCaractère "bonjou";
:zoneDeSaisieAprèsCaractère "bonjour";
:drapeauAway "0";
:contenuDeLaZoneDeSaisie "bonjour";
:contenuDuMasqueDeCouleurDeLaZoneDeSaisie "       ";
:positionDuCurseurDansLaZoneDeSaisie "7";
ktbs:hasBegin "1244635385";
ktbs:hasEnd "1244635385";
ktbs:hasTrace <> ;
].

[ a :presseTouche;
:versionDeWeechat "0.2.6.1";
:monPseudo "Damien_traces";
:nomDuCanal "#LIRIS";
:nomDuServeur "freenode";
:typeDeTampon (0=standard, 1=DCC, 2=données IRC brutes) "0";
:caractère "return";
:zoneDeSaisieAvantCaractère "bonjour";
:zoneDeSaisieAprèsCaractère "";
:drapeauAway "0";
:contenuDeLaZoneDeSaisie "";
:contenuDuMasqueDeCouleurDeLaZoneDeSaisie "";
:positionDuCurseurDansLaZoneDeSaisie "0";
ktbs:hasBegin "1244635386";
ktbs:hasEnd "1244635386";
ktbs:hasTrace <> ;
].

L'OGVIT est supposé construire automatiquement, à partir du modèle de la trace, la visualisation suivante.

Interface pour la visualisation de la trace des frappes clavier de weechat

On constate plusieurs choses :

  • c'est vide : ben oui, car je n'ai pas le modèle de cette trace, et d'une façon plus générale le format d'un modèle
  • il manque des informations pour construire la représentation de la trace : les noms (humains) des colonnes doivent provenir du modèle, ou du fichier de l10n associé.

Comme quoi, c'est vraiment là un problème technique et non pas scientifique. Il faut qu'on se force à prendre des décisions pour avancer.