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 :)