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

vendredi 9 avril 2010

Première version du prototype de l'OGVIT

J'ai l'immense plaisir, l'honneur et la joie de vous annoncer qu'une première version de développement de l'OGVIT (Outil générique de Visualisation Interactive de Traces) tourne.

Oh, certes, c'est du brut de décoffrage et il manque encore plusieurs choses, mais la tuyauterie est en place (malgré un problème clairement identifié et contourné), et il est possible de charger une trace produite pour la consulter, et même la tripoter un petit peu.

On peut découvrir sur la capture d'écran :

  • en haut à gauche : le debug du KTBS; on voit les requêtes entrantes et sortantes
  • à droite du KTBS : le collecteur de traces faisant le lien entre weechat et le KTBS; on voit les données internes et le traitement
  • à droite du collecteur de traces : weechat-traces, le client IRC instrumenté pour produire des traces; on voir l'activité dans le chat
  • en bas à droite : le debug de l'OGVIT; on y voit sa détection de l'affichage d'éléments partiellement ou complètement superposés
  • en travers de tout : l'OGVIT qui affiche la trace de weechat; on voit l'axe du temps, les observés codés par couleur (bleu : frappe clavier; rouge moche : connexion)

Première démonstration de l'OGVIT

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/

mardi 13 octobre 2009

Jouer avec un SGBT, c'est possible !

Il m'aura fallu un peu de temps, mais voici enfin deux scripts simples qui permettent de tester le KTBS de PA :

  • lancer_le_ktbs : démarre le KTBS en local
  • initialiser_le_ktbs : alimente le KTBS avec :
    • 1 utilisateur : alice
    • 1 modèle de trace : weechat
    • 1 trace : t01
    • 4 observés :
      1. joindre un canal
      2. envoyer un message
      3. recevoir un message
      4. quitter le canal

Avec ces scripts, il est possible de faire tourner un SGBT contenant des données afin d'interagir avec lui : demande d'observé, transformation, etc

Comment utiliser les scripts ? Facile.

-1) mettez en place un support IPv6 sur votre machine. Une adresse en fe80:* suffit

0) faites un checkout du KTBS : $ svn co https://svn.liris.cnrs.fr/sbt-dev/ktbs-rest-impl/trunk

1) ouvrez un terminal, et lancez le script lancer_le_ktbs avec comme argument le chemin vers bin/ktbs que vous venez de récupérer

Par exemple :

$ ./lancer_le_ktbs ../bin/ktbs 
=== Using IPV6
KTBS example at http://ip6-localhost:8001/

2) ouvrez un terminal, et lancez le script initialiser_le_ktbs. Admirez la sortie standard qui vous donne les valeurs de retour du KTBS (sauf celle de l'étape 2 qui est filtrée). Admirez également la sortie standard du KTBS qui vous indique les données reçues.

ip6-localhost - - [13/Oct/2009 16:26:51] "POST / HTTP/1.1" 201 0
ip6-localhost - - [13/Oct/2009 16:26:51] "POST /alice/ HTTP/1.1" 201 0
ip6-localhost - - [13/Oct/2009 16:26:52] "PUT /alice/weechat/ HTTP/1.1" 200 386
ip6-localhost - - [13/Oct/2009 16:26:52] "POST /alice/ HTTP/1.1" 201 0
ip6-localhost - - [13/Oct/2009 16:26:52] "POST /alice/t01/ HTTP/1.1" 201 0
ip6-localhost - - [13/Oct/2009 16:26:52] "POST /alice/t01/ HTTP/1.1" 201 0
ip6-localhost - - [13/Oct/2009 16:26:52] "POST /alice/t01/ HTTP/1.1" 201 0
ip6-localhost - - [13/Oct/2009 16:26:52] "POST /alice/t01/ HTTP/1.1" 201 0

Pointez maintenant votre navigateur préféré sur l'interface web du KTBS (http://ip6-localhost:8001/alice/t01/@obsels) et admirez votre trace (ou plus exactement celle d'Alice) de WeeChat conforme au modèle spécifié.



Vous pouvez maintenant travailler avec le KTBS.

jeudi 8 octobre 2009

Offre de poste : ingénieur des technologies web

Description du poste

Le LIRIS (laboratoire CNRS, UMR5205) / Université Lyon 1 recrute un ingénieur expérimenté au 1er janvier 2010 pour une durée de 20 mois. L'ingénieur travaillera dans l'équipe SILEX dans le cadre du projet ITHACA en lien avec des scientifiques du LIRIS, de l'Université Lyon 2 et du TECFA-Genève. Le projet ITHACA a pour objectif de mettre en place une plateforme web synchrone dédiée au tutorat dans l'enseignement supérieur, dotée de capacités réflexives permettant de favoriser la conscience d'activité de groupe et l'apprentissage. La plateforme sera spécialisée pour être utilisée dans le cadre de plusieurs formation universitaires à distance. Elle utilisera une plateforme de gestion de traces d'utilisation développée dans l'équipe SILEX du LIRIS, appelée SGBT (Système de gestion de bases de traces).

Les missions du candidats seront les suivantes :

  • développement de la plateforme Ithaca et du SGBT
  • coordination des développements de la plateforme Ithaca et du SGBT en liaison avec l'équipe technique de Lyon 2, et avec les autres projets de l'équipe SILEX
  • encadrements de stagiaires et intégration de leurs travaux, etc.

Les technologies utilisées sont des technologies web au sens large : serveur de médias Red5/java, Flex/Flash, python. Une connaissance de frameworks tels que Cairngorm ou Spring serait un plus, ainsi que de REST et RDF.

Le candidat devra justifier de quelques années d'expérience dans le domaine ou dans un domaine proche, il devra avoir des qualités relationnelles, de rédaction, de travail en équipe, etc. Il devra être capable d'être à la passerelle entre des utilisateurs non-techniques et des chercheurs en informatique.

Le poste sera situé à l'Université Claude Bernard Lyon 1

Salaire : > 2200 € net

Contact : envoyer CV + lettre de motivation à Pierre-Antoine.Champin@liris.CNRS.fr et Yannick.Prie@liris.CNRS.fr

Précisions

Rapidement, il s'agit de participer au développement d'une application Flash qui gère des flux audio/vidéo en simultané, avec en parallèle de transactions rapides sur des bases de données et différents services.

C'est un contrat de 20 mois, dans le cadre d'un projet de recherche. Il s'agit pour le candidat d'être leader sur sa partie du travail, mais il pourra (un peu) s'appuyer sur d'autres membres du projet pour des points précis. Nous recherchons quelqu'un qui soit immédiatement opérationnel sur les technologies web utilisées; il est important de bien maîtriser développement d'interfaces graphiques, y compris de nouveaux composants.

Globalement, c'est un boulot sympa, avec du volume mais rien de bien extraordinaire niveau complexité. Les partenaires du projet (différents universitaires) sont dynamiques, avec des profils variés (enseignement de langues, modélisation, visualisation interactive, suivi de l'activité, web sémantique...)

Je peux répondre à toutes vos questions sur ce poste, en privé ou en commentaire de ce billet.

En savoir plus :

Précisions diverses :

  • tout le développement informatique est placé sous des licences libres (GPLv2 et v3, précisément)
  • l'employeur est particulier, puisqu'il s'agit d'un projet de recherche universitaire (CNRS)
  • le projet comporte des personnes fortement impliquées dans le logiciel libre, qui contribuent au noyau linux ou à VLC
  • c'est une possibilité intéressante de travailler dans le logiciel libre : mission longue, correctement rémunérée
  • le projet s'appuie sur de nombreuses technologies libres déjà existantes (java, mysql, python, GNU/linux, HTTP, REsT, RDF, XML, apache), ainsi que sur des outils de recherches libres eux aussi (advene, SGBT)

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());
}

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.

lundi 8 juin 2009

Diigo : un outil de web social

Diigo est un outil d'enrichissement partagé du web.

Ses principales fonctionnalités sont :

  • la gestion de bookmarks en collections (comme Reddit)
  • la gestion de groupes d'utilisateurs (comme Reddit)
  • le partage de bookmarks entre utilisateurs et groupes (comme Reddit)
  • le marquage par tags de bookmarks (comme Reddit)

Jusqu'ici, que du très classique me direz-vous. Là où Diigo devient intéressant, c'est avec ses possibilités d'enrichissement du contenu.

Il est ainsi possible d'annoter une page web, de la même façon qu'on annoterait un PDF. Ces annotations peuvent être privées ou partagées. Des outils permettent de trouver rapidement toutes les annotations partagées au sein d'un groupe et de les consulter, autorisant ainsi une lecture collective asynchrone de ressources web.

Les annotations sont attachées à des éléments précis d'une page web (zone de texte, par exemple) pour créer une forte contextualisation.

Annotations dans Diigo

Lors de la navigation web, il est possible de filtrer les annotations existant pour une page afin de ne visualiser que celles provenant de personnes ou de groupe précis.

Filtrage des annotations dans Diigo

Également, Diigo permet des commenter des pages et sites web. À la différence des annotations, ces commentaires sont globaux et approprié à la mise en place de discussions simples.

Commentaires dans Diigo

En revanche, Diigo ne permet que de « plusser » des bookmarks afin de leur attribuer une note globale, là où d'autres outils (comme Reddit) ont plus de possibilités.

Une des fonctionnalités de Diigo est très intéressante pour SILEX : il est possible de s'abonner aux flux RSS de presque tous les éléments existants : activité des membres d'un groupe, annotations liées à une page, commentaires, mot-clé, etc. Ce qui veut dire qu'en mettant en place un préparateur de trace RSS→observé on a la possibilité d'alimenter le SGBT, et donc d'avoir un traçage d'une activité collective tournant autour des bookmarks.

Ah oui, et aussi : Diigo pourrait permettre à SILEX de partager simplement des trouvailles sur le web ;)