Goffi non-hebdo

Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - technique

Fil des billets - Fil des commentaires

lundi 10 février 2014

Ligne de commande: passage de jp à argparse

Salut à vous,

jp, l'interface en ligne de commande de « Salut à Toi », vient de subit un gros ré-usinage. C'était auparavant un script fait rapidement qui permettait d'appeler quelques méthodes de SàT. Il est passé à argparse, grâce notamment à la contribution de Dal - merci à lui - et est désormais mieux organisé.

En effet, un des gros intérêts de argparse est sa gestion des sous-commandes, similaire à ce qu'on voit dans les gestionnaires de versions (comme svn co ou hg push). On peut ainsi élaborer des lignes de commandes complexes relativement facilement.
Par exemple, les commandes pour envoyer un message se forment avec « jp message »: « echo 'Salut à Toi !' | jp message -p goffi louise » enverra ainsi un message au contact nommé « louise » présent dans la liste (le roster). Ces commandes sont associées à des modules python (auparavant tout était dans un gros blog unique) plus ou moins court, ce découpage va permettre d'étendre jp facilement.

J'en ai profité pour faire un script de complètement pour zsh, qui s'adapte en fonction des commandes disponible. Il est également capable de compléter le profil quand nécessaire, et il devrait à terme être capable de compléter les jids ou les groupes selon ce qui est disponible dans votre roster.

Complètement de jp dans zsh

Bref, jp a tout ce qu'il faut pour devenir un couteau suisse XMPP, et permettre une utilisation simple et efficace de SàT en ligne de commande ou dans un script.

dimanche 7 avril 2013

Correction licence dans les fichiers d'Urwid SàText / Licence fix in Urwid SàText files

english below,

Bonjour,

comme on me l'a fait remarquer, les en-têtes d'Urwid SàText étaient incorrects, ils indiquaient une GPL v3+ alors que ce projet est désormais en LGPL v3+ (attention, on parle bien d'Urwid SàText, Salut à Toi est lui en AGPL v3+). Les en-têtes sont maintenant corrigés (rev 5cef69971f23).

Goffi

Hello,

as somebody pointed out, the Urwid SàText headers were incorrects, they were annoucing a GPL v3+ while the project is now a LGPL v3+ one (carreful, we are talking about Urwid SàText, the « Salut à Toi » project is AGPL v3+). The headers are now fixed (rev 5cef69971f23).

Goffi

vendredi 22 février 2013

Export command to a contact (with video)

G'day everybody,

I have made a small plugin for fun which export the input/outputs of an Unix command to a contact. The principle is really simple: you enter a command (so far it's not implemented in the frontends, so you'll have to directly use the D-Bus API, throught e.g. D-Feet or qdbus), then the contacts allowed to communicate with it, with options if necessary, and voilà !

There are 2 mains advantages by doing this:

the first one is that you can give access to an interpreter to any of your contacts (I'm doing this with FTP in the video, I have also made tests with bc, ipython or zsh), without using heavy tools like ssh which need to create an access account, a client, an opened port, etc. Of course, it's not elaborated, it's not a terminal, but it can help out. The escape sequences (what bring colors and others things in your interpreter) are not managed yet, and it can scramble your output (I had the case with ipython). I'm thinking about catching them, and convert to color with XHTML-IM (well, a first step would be that SàT manage XHTML-IM :p ).

the second one is to help to write bots really quickly: you just have to make a script with read stdin and react to it. You can make a bot in a couple of minutes with any scripting language (sh, Python, Ruby, etc) or others. And you can directly debug it from a terminal, without the need of an XMPP server to test it. To show you how easy it is, I have made a little test in Python, here what it looks like:

#!/usr/bin/python
#-*- coding: utf-8 -*-
import sys

class QuickBot(object):

    def out(self, msg):
        sys.stdout.write((u"%s\n" % msg).encode('utf-8'))
        sys.stdout.flush()

    def start(self):
        while(True):
            _input = raw_input().decode('utf-8','ignore')
            if _input.startswith('!'):
                args = _input[1:].split()
                try:
                    getattr(self, "cmd_%s" % args[0].encode('ascii').lower())(args[1:])
                except (IndexError, AttributeError, UnicodeEncodeError):
                    pass

    def cmd_salut(self, args):
        self.out(u"à Toi !")

if __name__ == "__main__":
    bot = QuickBot()
    bot.start()

The contact just have to enter !command [arguments] to make it do something (here !salut). To add a new command, you just have to create a new method named cmd_my_command, e.g. cmd_toto will add the command !toto. Easy isn't it ?

I have made a short video to show you this, it's in french but easy to understand even without sound, where I export a FTP server.

I have also made a small web widget for Libervia (it's not pushed on the repository yet). Of course it's limited (because of javascript security restrictions), but it allow to show whatever you want beside your conversations, and to enjoy Libervia's layout management (you'll can, for example, put 4 websites on a grid).

See you soon

As usual, to watch the video you can use a recent browser (the last Firefox/Iceweasel for example).
You can also use VLC (version >=1.1 only), by using the "Media/Open Netword Stream" menu and by entering this URL: http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_6_export_commande.webm
Last but not least, you can use mplayer:: mplayer "http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_6_export_commande.webm"

this video is licenced under Creative Common BY-SA

Export de commande à un contact (avec vidéo)

Salut à tous,

edit: la vidéo a été à peu près resynchronisée :)

je me suis amusé à faire un greffon qui exporte les entrées/sorties d'une commande Unix à un contact. Le principe est très simple: vous entrez une commande (pour l'instant ce n'est pas implémenté dans les frontaux, aussi il faut utiliser directement l'API D-Bus, via D-Feet ou qdbus par exemple), ainsi que les contacts autorisés à communiquer avec, quelques options éventuelles et c'est parti !

Il y a 2 intérêts principaux à faire ceci:

le premier est que vous pouvez donner l'accès à un interprète à n'importe lequel de vos contacts (je fais un exemple avec FTP dans la vidéo, j'ai également fait des tests avec bc, ipython et zsh), sans utiliser de machineries lourdes telles que ssh qui demandent la création d'un accès, d'avoir un client, un port ouvert etc. Bon évidemment ça reste très simpliste, ce n'est pas un terminal, mais ça dépanne. Les caractères d'échappements (ce qui donne des couleurs par exemple dans un interprète) ne sont pas gérés, et ça peut donner de la bouillie (j'ai eu le cas avec ipython). J'envisage de les intercepter et les convertir en couleur via XHTML-IM à terme (enfin faudrait déjà gérer XHTML-IM dans SàT :p ).

le second est de permettre de faire des bots très facilement: il suffit de faire un script qui lit l'entrée standard et réagit en conséquence. Vous pouvez faire ainsi un bot en quelques minutes avec n'importe quel langage de script (sh, Python, Ruby, etc) ou autre. Et vous pouvez directement le déboguer dans un terminal, sans avoir besoin de serveur XMPP pour tester. Pour vous montrer la simplicité de la chose, j'ai fait un petit essai en Python, voici ce que ça donne:

#!/usr/bin/python
#-*- coding: utf-8 -*-
import sys

class QuickBot(object):

    def out(self, msg):
        sys.stdout.write((u"%s\n" % msg).encode('utf-8'))
        sys.stdout.flush()

    def start(self):
        while(True):
            _input = raw_input().decode('utf-8','ignore')
            if _input.startswith('!'):
                args = _input[1:].split()
                try:
                    getattr(self, "cmd_%s" % args[0].encode('ascii').lower())(args[1:])
                except (IndexError, AttributeError, UnicodeEncodeError):
                    pass

    def cmd_salut(self, args):
        self.out(u"à Toi !")

if __name__ == "__main__":
    bot = QuickBot()
    bot.start()

Le contact n'a qu'à faire !commande [arguments] pour le faire réagir (ici !salut). Pour ajouter une commande, il suffit de faire une nouvelle méthode nommée cmd_ma_commande, par exemple cmd_toto ajoutera la commande !toto. Facile non ?

J'ai fait une petite vidéo pour vous montrer ça à l'œuvre, désolé pour le décalage du son, j'ai probablement mal réglé un paramètre, et je n'ai pas trop le temps de recommencer 15 fois.

Bon sinon j'ai également fait un petit widget web pour Libervia (il n'est pas encore poussé sur le dépôt). Évidemment c'est limité (à cause des restrictions javascript), mais ça permet d'afficher ce que vous voulez à côté de vos discussions, et de profiter des possibilités de mise en page de Libervia (on pourra par exemple, mettre 4 sites dans une grille).

Enfin, n'oubliez pas que demain aura lieu un hackathon dans les locaux du Loop, cf mon précédent billet.

À bientôt

Comme d'habitude, pour lire la vidéo, vous devez utiliser un butineur récent (le dernier Firefox/Iceweasel par exemple).
Vous pouvez aussi utiliser VLC (version >=1.1 uniquement), en allant dans le menu « Média/Ouvrir un flux réseau » et en mettant cette URL: http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_6_export_commande.webm
Enfin, vous pouvez utiliser mplayer: mplayer "http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_6_export_commande.webm"

Cette vidéo est sous la licence Creative Common BY-SA

mardi 12 février 2013

Hackathon « Salut à Toi » les 23 et 24 février à Paris.

Les 23 et 24 février prochain aura lieu un hackathon autour du projet « Salut à Toi » dans les locaux du loop à Paris (XIVème). Ce sera l'occasion à la fois de faire avancer certaines fonctionnalités rapidement, et de permettre à ceux qui veulent contribuer de découvrir le code.

Pour mémoire « Salut à Toi » est un client XMPP multi-interfaces qui propose des fonctionnalités comme le microblogage, vous pouvez consulter les billets précédents pour mieux le connaître/essayer la démo.
Le projet est principalement développé en Python, mais on peut utiliser pratiquement n'importe quel langage pour développer un frontal. Le frontal « Bellaciao » est d'ailleurs développé en C++/Qt.

Contactez moi (via les commentaires ci-dessous par exemple ou par courriel à goffi@goffi.org, ou via XMPP à goffi@jabber.fr) si vous souhaitez participer.
Un grand merci au loop pour prêter leur local.

Accès au loop: http://wiki.leloop.org/index.php/Accès

L’événement devrait commencer aux alentours de 10h.

Edit: une liste de choses à faire a été commencée sur le wiki: http://wiki.goffi.org/wiki/Hackathon_22_02_2013, n'hésitez pas à la compléter, ou indiquer si vous souhaitez voir plus particulièrement une des fonctionnalités implémentée (ou y contribuer).

lundi 3 décembre 2012

Nouvelles de SàT + conférences

Salut à tous,

voici quelques infos en vrac sur l'évolution du projet, ainsi que les vidéos des dernières conférences (voir plus bas).

Une nouvelle version est proche (oui je sais ça fait longtemps que je l'annonce, mais c'est vraiment le cas), je suis actuellement en train d'implémenter les dernières fonctionnalités que je voulais voir dans Libervia.

Primitivus est désormais modal, à la vi: cela signifie que l'ont peut utiliser un mode adapté à ce que l'on fait (pour l'instant il y a 3 modes: normal, commande et insertion). L'intérêt est encore limité (il n'y a qu'une commande :quit), mais le but était de préparer le terrain pour des futures fonctionnalités (je pense notamment à des commandes du style :split et :vsplit).

Une nouvelle extension a vu le jour: un perroquet (parrot). Cette extension simple permet de répéter tous les messages entre 2 contacts. L'idée est de pouvoir faire communiquer 2 personnes (ou plus) sur 2 réseaux différents (par exemple IRC et SIP) sans que celles-ci n'aient besoin de créer un compte ou faire quoi que ce soit de particulier.
Certains bots faisaient déjà ça, l'avantage ici est que la mise en place est simple et rapide. Grâce aux transports XMPP, de nombreuses combinaisons sont possibles. Le principe sera peut-être étendu à terme au microblogage (ainsi en postant un microbillet XMPP, on pourrait le voir copié automatiquement sur d'autres réseaux - par exemple identi.ca, IRC, un forum, etc -).

Une autre extension permet désormais d'utiliser les commandes textuelles de type IRC (par exemple: « /nick nouveau_pseudo » dans une discussion de groupe). Ainsi un perroquet se met en place entre 2 contacts en écrivant « /parrot mon_autre_contact » à un contact.

Après avoir hésité à implémenter le partage de fichiers avant de sortir une nouvelle version, je pense qu'il est plus sage de le faire après, pour éviter de repousser sine die.

J'ai fait cet été une conférence aux RMLL à Genève (voir ci-dessous). Le salon était intéressant, Salut à Toi était à côté des projets amis Weboob et MOVIM.

Une autre conférence a eu lieu aux JDLL. N'étant pas officiellement filmée, nous avons fait une vidéo de fortune que vous trouverez ci-dessous. Les diapos ne sont pas visibles, aussi la présentation est jointe au billet.

Les deux vidéos (et la présentation) sont sous licence CC By-SA. J'en profite pour remercier les organisateurs de ces 2 salons, c'est agréable de pouvoir discuter directement avec les gens qui s'intéressent au projet.

À bientôt, probablement pour l'annonce de la nouvelle version.

Goffi

RMLL 2012

Cette vidéo est sous licence Creative Common BY-SA (merci à l'équipe des RMLL pour la prise de vidéo, vous trouverez cette conférence ainsi que les autres sur http://video.rmll.info)

JDLL 2012

Cette vidéo est sous licence Creative Common BY-SA

Présentations

dimanche 24 juin 2012

Fine access tuning for PubSub

Warning this post is technical

As you may know, "Salut à Toi" allow to do microbloging with groups access, that mean that you can send post to only a group of your roster (e.g. "family" or "friends"). This feature has been available for a year, but was using a dirty hack (which only works with OpenFire); that was mainly a proof of concept

We need a simple permissions system which can be used beyond microblogging, something generic, which can extend PubSub.
Rather than thinking about tons of pubsub nodes with different access model each time (e.g. a family node, an other one for friends, etc), we need a way to fine tune permissions, by items.

For this reason, I started a pubsub component to validate the concept, and which will be used by SàT to manage microblogging. If the idea proove to be working, I'll talk about it on one of the XSF mailing list, to propose it as a standard.

The way it works is simple: we use exactly the same syntax as for nodes access model (http://xmpp.org/extensions/xep-0060.html#accessmodels), and we apply it to items.
The node access model is applied first, then the ones of items (that mean that an item with an open access model won't be available to somebody which is not in the right roster group if the node has a roster access).
The PubSub component parse the item stanza, apply access model, then save it (without the configuration part).
When somebody wants to get node's items, the pubsub component first check that he is granted to access node (by checking the "access model"), then send him only the items that he can access.

Imagine that Louise has a node with 3 items: 1 with an open access (A), 1 with a roster access, allowed for "family" group (B), and one with a roster access, allowed for "friends" and "coworkers" (C).
Pierre, who is a friend of Louise, will have access to items A and C. Louise's brother will access items A and B.

There a 2 main advantages: first this protocol stay standard compliant (with XEP-0060) - so there is no change to do for an XMPP client to get items -, and secondly the clients have only one node to check by entity that they want to follow.

Some words on test implementation: I use the "Idavoll" PubSub component as a basis, which was made by Ralph Meijer*, and I have slightly modified it for my tests. The main difficuly is that currently components have a very limited access to server, and we can't access entities' roster.
To work around the issue, I use an experimental protocol which allow to access a remote roster. Unfortunately, this protocol only permit to access a part of the roster, so I have patched Prosody's implementation to get the full roster.
Finally, I used some simplifications by saying that node creator, owner and publisher are the same. This is often true for microblogging, but is very limiting when we think about XEP-0060's possibilities.

Anyway it works, but it still need works (and a standardisation) before being a proper way to do.

Below is a server dialog example. We have here Pierre and Louise which are friends, Louise being in "friends" group of Pierre. The later post a microblog as follow**:
<iq from="pierre@example.net/SàT" type="set" id="H_77" to="sat-pubsub.example.net">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <publish node="urn:xmpp:groupblog:pierre@example.net">
      <item id="8f532cc8-be1d-11e1-b5d3-00c0ca4f1546">
        <entry xmlns="">
          <title>G'day my friends !</title>
          <id>8f532cc8-be1d-11e1-b5d3-00c0ca4f1546</id>
          <updated>2012-06-24T18:56:36+02:00</updated>
          <author><name>pierre@example.net</name></author>
        </entry>
        <x xmlns="jabber:x:data" type="submit">
          <field var="FORM_TYPE" type="hidden">
            <value>http://jabber.org/protocol/pubsub#item-config</value>
          </field>
          <field var="pubsub#access_model">
            <value>roster</value>
          </field>
          <field var="pubsub#roster_groups_allowed">
            <value>friends</value>
          </field>
        </x>
      </item>
    </publish>
  </pubsub>
</iq>

After receiving this, the server parse configuration data (the "http://jabber.org/protocol/pubsub#item-config" form***), delete this part of the stanza, save the item with the right permissions (roster access, only for "friends" group), and only send a notification to group's members, so it send one to Louise.

The notification is sent like this:

<message to="louise@example.net" from="sat-pubsub.example.net">
  <event xmlns="http://jabber.org/protocol/pubsub#event">
    <items node="urn:xmpp:groupblog:pierre@example.net">
      <item id="8f532cc8-be1d-11e1-b5d3-00c0ca4f1546">
        <entry xmlns="">
          <title>G'day my friends !</title>
          <id>8f532cc8-be1d-11e1-b5d3-00c0ca4f1546</id>
          <updated>2012-06-24T18:56:36+02:00</updated>
          <author><name>pierre@example.net</name></author>
        </entry>
      </item>
    </items>
  </event>
</message>

There is no way to know on which group Louise is in Pierre's roster (this is a classical notification). Even is an XMPP client doesn't manage the per-item access model, it will receive the notifications and will be able to manage them as usual.

I have sub-licenced the component to AGPL V3, you will find the code in my repository (http://repos.goffi.org/sat_pubsub/). I invite XMPP community's members (authors of clients and servers, or others) to use the code, or to comment the idea

Fine permissions tuning are in my opinion a mandatory feature that XMPP really needs, and they will be more and more used by the "Salut à Toi" project. It was one of the last architecture point of SàT, a new release should follow quickly.

Stay connected :)
Goffi

* Ralph Meijer is also a contributor of Twisted and the author of "Wokkel" library, which are in the heart of SàT, in addition of being one of the authors of PubSub XEP. A huge thank to him for its valuable contributions.
** Normally, microbloging use PEP, but component limitation that I mentionned above forced me to use a custom protocol, which doesn't use PEP.
*** I have used a "jabber.org" namespace instead of "goffi.org", as I should have do for an experimental feature, because I need it so Wokkel's PubSub service could parse it.

Permissions fines pour PubSub

Attention ce billet est technique.

Comme vous le savez peut-être, « Salut à Toi » permet de faire du microblogage par groupes, c'est à dire que vous pouvez envoyer des messages réservés à un groupe de votre roster (par exemple « famille » ou « amis »). Cette fonctionnalité est disponible depuis près d'un an, mais était basée sur un bidouillage assez sale (et qui ne fonctionne qu'avec OpenFire), qui permettait surtout de tester le concept.

Il est nécessaire d'obtenir un système de permissions simple qui va au delà du microblogage, quelque chose de générique, qui étendrait PubSub.
Plutôt que de partir sur des tonnes de nœuds pubsub avec des accès différents à chaque fois (par exemple, un nœud pour la famille, un pour les amis), il faut un moyen de gérer plus finement les permissions, par élément (item).

Aussi j'ai commencé un composant pubsub qui permet de valider le concept, et qui va être utilisé par SàT pour gérer le microblogage. Si l'idée se montre solide en pratique, je vais en parler sur une des listes de diffusion de la XSF pour tenter de la faire standardiser.

Le fonctionnement est assez simple: on prend exactement la même syntaxe que les accès du nœud (« Node Access Models » (http://xmpp.org/extensions/xep-0060.html#accessmodels) qu'on applique aux éléments.
L'accès du nœud est appliqué en premier, puis celui des éléments (c'est à dire qu'un élément avec un accès ouvert (open) ne sera pas accessible à quelqu'un qui n'est pas dans le groupe prévu si le nœud a un accès par groupe (roster)).
Le composant PubSub parse l'élément, applique les permissions, puis le sauvegarde (sans la partie configuration).
Quand quelqu'un veut récupérer les éléments du nœud, le composant pubsub vérifie d'abord qu'il a accès au nœud (en vérifiant le « access model »), puis lui envoi uniquement les élements qui correspondent à son accès.

Imaginons que Louise a un nœud avec 3 éléments: 1 qui a un accès ouvert (A), 1 qui a un accès par groupes, autorisé pour le groupe « famille » (B), et un qui a un accès par groupes, autorisé pour les groupes « Amis », et « Collègues » (C).
Pierre qui est un ami de Louise aura accès aux élements A et C. Le frère de Louise aura accès aux éléments A et B.

Il y a là 2 avantages principaux: premièrement ce protocole reste compatible avec la XEP-0060 - il n'y a donc aucun changement à faire côté client pour retrouver les élements -, et deuxièmement les clients n'ont qu'un seul nœud à surveiller par entitée suivie.

Quelques mots sur l'implémentation de test: j'ai pris pour base le composant PubSub « Idavoll », fait par Ralph Meijer*, que j'ai légèrement modifié pour faire les tests. La difficulté principale est qu'actuellement un composant a un accès très limité au serveur, et ne peut notamment pas acceder au roster des entités.
Pour contourner le problème, j'utilise un protocole expérimental, qui permet d'accéder à un roster distant. Malheureusement, ce protocole ne permet que d'accéder à une partie du roster, aussi j'ai du modifier l'implémentation de Prosody pour récupérer le roster complet.
Enfin, j'ai simplifié en considérant que le créateur du nœud était aussi son propriétaire, et l'auteur des billets (creator = owner = publisher). Ce qui est souvent vrai pour du microblogage, mais limite beaucoup les possibilités offertes par la XEP-0060.

Bref, ça fonctionne, mais il y a encore du travail à faire (et qui doit passer par une phase de standardisation) avant que ça soit propre.

Voici un exemple de dialogue avec le serveur. Nous avons ici Pierre et Louise qui sont amis, Louise est dans le groupe « amis » de Pierre. Ce dernier publie un microbillet comme suit**:
<iq from="pierre@example.net/SàT" type="set" id="H_77" to="sat-pubsub.example.net">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <publish node="urn:xmpp:groupblog:pierre@example.net">
      <item id="8f532cc8-be1d-11e1-b5d3-00c0ca4f1546">
        <entry xmlns="">
          <title>Salut les amis !</title>
          <id>8f532cc8-be1d-11e1-b5d3-00c0ca4f1546</id>
          <updated>2012-06-24T18:56:36+02:00</updated>
          <author><name>pierre@example.net</name></author>
        </entry>
        <x xmlns="jabber:x:data" type="submit">
          <field var="FORM_TYPE" type="hidden">
            <value>http://jabber.org/protocol/pubsub#item-config</value>
          </field>
          <field var="pubsub#access_model">
            <value>roster</value>
          </field>
          <field var="pubsub#roster_groups_allowed">
            <value>amis</value>
          </field>
        </x>
      </item>
    </publish>
  </pubsub>
</iq>

En recevant ceci, le serveur analyse les données de configuration (le formulaire « http://jabber.org/protocol/pubsub#item-config »***), supprime cette partie du message, stocke l'élements avec les permissions voulues (accès par groupes, uniquement pour le groupe « amis »), et envoi une notification uniquement aux membres du groupe « amis », soit à Louise.

La notification est envoyée comme suit:

<message to="louise@example.net" from="sat-pubsub.example.net">
  <event xmlns="http://jabber.org/protocol/pubsub#event">
    <items node="urn:xmpp:groupblog:pierre@example.net">
      <item id="8f532cc8-be1d-11e1-b5d3-00c0ca4f1546">
        <entry xmlns="">
          <title>Salut les amis !</title>
          <id>8f532cc8-be1d-11e1-b5d3-00c0ca4f1546</id>
          <updated>2012-06-24T18:56:36+02:00</updated>
          <author><name>pierre@example.net</name></author>
        </entry>
      </item>
    </items>
  </event>
</message>

Rien ne permet de savoir à quel groupe Louise appartient dans le roster de Pierre (c'est une notification traditionnelle). Même si un client XMPP ne gère pas les permissions fines, il recevra les notifications et pourra les traîter comme d'habitude.

J'ai relicencié le composant en AGPL V3, vous pouvez trouver le code dans mon dépôt (http://repos.goffi.org/sat_pubsub/). J'invite les différents membres de la communauté XMPP (auteur de clients/serveurs ou autre) à utiliser le code, ou à apporter des critiques au principe.

Les permissions fines sont à mon avis une fonctionnalité essentielle et nécessaire dans XMPP, et elles vont être de plus en plus utilisées par le projet « Salut à Toi ». Il s'agissait de la dernière grosse brique de l'architecture de SàT, une nouvelle version devrait suivre rapidement.


Restez en ligne :)
Goffi

* Ralph Meijer est aussi un contributeur de Twisted et l'auteur de la bibliothèque « Wokkel » qui sont au cœur de SàT, en plus d'être un des auteurs de la XEP PubSub. Un grand merci à lui pour ses précieuses contributions.
** Normalement le microblogage utilise PEP, mais les limitations des composants évoquées plus haut m'ont obligé à utiliser une variante du protocole qui ne passe pas par PEP.
*** J'ai du utiliser un espace de nommage en « jabber.org » plutôt qu'un « goffi.org », comme j'aurais du le faire pour une fonctionnalité expérimentale, pour pouvoir être parsé par le service PubSub de Wokkel.

vendredi 7 octobre 2011

Shell: pipe you commands out via XMPP with SàT

G'day all,

just a short notice to show a feature i'm currently implementing, the hability to pipe out a command line stream via XMMP, using jp, the command line frontend of the "Salut à Toi" project.

The syntax is quite easy: imagine you have 2 people Pierre and Louise talking together. Louise is talking about the last Blender Foundation movie, Sintel, and Pierre is interested, and want to see the trailer Louise is talking about. To do that, he just has to enter the following command:

jp --pipe-in louise | mplayer -


Which mean "I'm waiting for an incoming stream from louise". Louise correspond to the name Pierre gave to its contact louise@example.org, jp do the association.
He could also have used the full jid instead: louise@example.org/Noumea .

In the other side, Louise can pipe out the trailer to Pierre with the following command:

cat sintel_trailer-480p.ogv | jp --pipe-out pierre

Quite easy isn't it ? You don't have to worry about the IP address of your contact, just to know its jid, or to have it in your roster with an easy-to remember name.

Note that jp was already allowing you to pipe out command line result as a XMPP message (to do some ascii art for example ;) ).

If you want to copy a file, the syntax is quite similar:

jp -wg louise

for reception and:

jp -g sintel_trailer-480p.ogv pierre

to send the file. The -g flag means you want to see the progress bar.

The following short video show this in action. It's in french, but you don't really need the comments to understand it.


To play the video, you nead a recent browser (e.g. Firefox 4+ or the last Chromium).
You can also use VLC (>=1.1 only), by using this url as a flux: http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_4_copie_et_pipe.webm

Last but not least, you can use mplayer: mplayer "http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_4_copie_et_pipe.webm"

This video is licensed under Creative Common BY-SA

For the technical side, it's just a modified XEP-0096 . It would be intersting to propose this as a standard to the XSF, but maybe by using jingle transfer instead.

Please not that all of this is really experimental.

I plan to release the next version of "Salut à Toi" soon, stay connected :)

Ligne de commande: envoyez vos tubes (pipes) par XMPP (avec vidéo)

Salut à vous,
une nouvelle vidéo, très courte, pour vous montrer 2 choses:
  • la copie (transfert de fichier pour faire plaisir à Neustradamus) qui a été améliorée, vous avez ici un exemple avec jp - le frontal en ligne de commande -. J'avais déjà fait une démo dans la première vidéo, mais cette fois la syntaxe est simplifiée (plus besoin de fournir le jid complet), et sous le capot les protocoles ont été améliorés (gestion de in-band bystreams et gestion du proxy dans Socks5), bien que pas tout à fait fini.
  • j'en ai profité pour ajouter une nouvelle fonctionnalité qui devrait plaire aux amoureux de la ligne de commande: la possibilité d'envoyer la sortie d'un tube (pipe) par XMPP.
    La vidéo montre ça en action en streamant une vidéo par XMPP.

    C'est un test que j'ai fait, et c'est juste une légère modification de la XEP-0096. Ça peut être intéressant d'essayer de standardiser ça, peut être en passant par jingle.
Tout ça est encore très expérimental - et en cours de finition -, tout retour est le bienvenu.

Comme d'habitude, pour lire la vidéo, vous devez utiliser un butineur récent (Firefox 4 ou le dernier Chromium par exemple).
Vous pouvez aussi utiliser VLC (version >=1.1 uniquement), en allant dans le menu « Média/Ouvrir un flux réseau » et en mettant cette URL: http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_4_copie_et_pipe.webm

Enfin, vous pouvez utiliser mplayer: mplayer "http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_4_copie_et_pipe.webm"

Cette vidéo est sous la licence Creative Common BY-SA

mercredi 31 août 2011

Comment changer la disposition du clavier (keyboard layout) sous Android

Bonjour à tous,
j'ai depuis peu une tablette Android, dont j'aimerais me servir comme portable en y ajoutant clavier/souris, et me permettre ainsi de travailler sur mes projets quand je bouge.

Android n'étant pas vraiment prévu pour ça à la base, il faut bidouiller pas mal (rooter la tablette, installer un GNU/Linux dans un chroot, ou en natif si possible, ou au minimum cross-compiler des outils comme vim). Un des mes problèmes a été que la disposition clavier par défaut est QWERTY, alors que mon clavier, acheté en France, est AZERTY. Ne connaissant pas (encore) Android, j'ai du chercher un peu, et j'ai finalement trouvé une solution qui fonctionne bien, donc voici un petit tuto qui peut éventuellement servir à d'autres (sous CC By-SA si vous voulez vous en servir), j'ai fait le même en anglais sur le site tabletroms: http://tabletroms.com/forums/showwiki.php?title=NotionInkAdamFAQ:Howto-change-keyboard-layout

Pour changer la disposition clavier, il vous faut (à adapter selon votre matériel): votre tablette sous Android (testé sous une ROM derivée d'Honeycomb - Adamcomb v0.3 - sur une tablette Adam de Notion Ink) qui doit être rootée, une émulateur de terminal (on en trouve un libre sur l'Android Market, dommage qu'il ne soit pas (encore) sur le dépôt libre F-Droid, et un moyen de copier un fichier sur une machine GNU/Linux (ici une carte micro SD, mais vous pouvez faire l'édition directement depuis l'émulateur de terminal, c'est juste un peu plus galère).
Ici la carte micro SD est montée sur /mnt/external_sd.
Les étapes à faire:
  • lancer l'émulateur de terminal, passez à l'utilisateur root, puis copiez les fichier de /system/usr/keylayout et /system/usr/keychars sur votre carte:

    su
    cp -r /system/usr/key* /mnt/external_sd/
  • démontez votre carte, et montez là sur votre GNU/Linux. Nous allons maintenant déterminer l'identifiant de votre clavier usb, aussi gardez-le près de vous mais ne le branchez pas. Commencez par sauver les informations des périphériques déjà présents:

    lsusb > /tmp/1
  • maintenant branchez votre clavier, et faire la même chose, le diff vous donne les informations qui nous intéressent:

    lsusb > /tmp/2
    diff /tmp/1 /tmp/2
  • Par exemple pour mon clavier, ça donne:

    > Bus 002 Device 005: ID 04d9:1503 Holtek Semiconductor, Inc. Shortboard Lefty
    La partie importante est 04d9:1503 (04d9 est l'id du vendeur, 1503 celle du produit)
  • maintenant branchez votre clavier, et faire la même chose, le diff vous donne les informations qui nous intéressent:

    lsusb > /tmp/2
    diff /tmp/1 /tmp/2
  • Sur votre carte que nous avons montée, utilisez les fichiers keylayout/Genric.kl et keychars/Generic.kcm comme références, et copiez les dans des fichier sous la forme Vendor_xxxx_Product_xxxx.ext, par exemple chez moi ça donne:

    cp keylayout/Genric.kl Vendor_04d9_Product_1503.kl
    cp keylayout/Genric.kcm Vendor_04d9_Product_1503.kcm
    Éditez ces fichiers (avec vim, kate, gedit ou ce que vous voulez), leur contenu est facile à comprendre. Vérifiez bien que les noms (label) du fichier characters map (.kcm) correspondent à ceux du fichier layout (.kl).
  • Une fois que vous avez édité et sauvé les fichiers, démontez votre carte et remontez la sur votre appareil sous Android. Retournez sur votre émulateur de terminal, et copiez les fichiers (toujours en avec root)

    cp /mnt/external_sd/Vendor_xxxx_Product_xxxx.kl /system/usr/keylayout
    cp /mnt/external_sd/Vendor_xxxx_Product_xxxx.kcm /system/usr/keychars
    chmod 644 /system/usr/keylayout/Vendor*kl
    chmod 644 /system/usr/keychars/Vendor*kcm
  • C'est tout ! Vous n'avez plus qu'à brancher votre clavier, pas besoin de redémarrer.
Tout ceci a été testé comme indiqué plus haut sur le Adam, il est possible que cela ne fonctionne pas, ou différemment sur un autre appareil. Notez aussi que les manipulations sous root peuvent être dangereuses, et que vous pouvez facilement rendre votre appareil inutilisable si vous ne savez pas ce que vous faites, aussi allez y à vos risques et périls.

dimanche 5 juin 2011

Salut à Toi: a multi-frontends XMPP client

G'day all,

I have been working for a while on an XMPP client with a daemon/frontends architecture: the idea is that you have the main logic centralised in the daemon side, and you can make very different lightweight frontends for the view. The project is intended to be a modular, multi-platform, multi-frontend communication software. The frontends can be adapted to a particular use case, or platform.
Currently, there are a desktop frontend, a console frontend, a command-line frontend, and a web frontend. A Kde frontend is also planned.

The project is quite difficult to summarise, as it touch a lot of domains (it's not intended to be only an instant messaging software, but to explore deeply the power of XMPP): with it you have instant messaging, e-mail style heavy messaging, multi-user chat, microblogging, file sharing, games, etc.

Techical part

Salut à Toi (SàT) - which means « Hi to you » - is heavily based on the Twisted framework, and the XMPP library Wokkel, which is on top of it and should be integrated in Twisted in the future. The core backend concentrate only on the RFC, a couple of XEP, and the essential stuff to run. Most of the XEP and the advanced functionalities are put in plugins, that allow the code to be modular, and to choose which features you want (you can remove plugins to suppress features for e.g. a public station). SàT manage several profiles: you can use different profiles for different accounts on different servers.


The backend communicate with the frontends throught a "bridge", which is actually an IPC: so far, D-Bus is used, but it is possible to use an other one. All the frontends and the backend together make one client, that means that if you enter something in one frontend, it will appear in the other ones like if it was enterred there. It also means that the history of the conversations is shared, and that if you create one profile somewhere, it will be created globally.


As the backend is independent of the frontends, you can use SàT without graphical interface (i.d. without X running), or unplug a frontend while the backend is still running (e.g. to terminate a long file transfert).
As you can guess by seeing Twisted, SàT is made with Python, it is actually 100% Python, including browser side code (see below); but an other language can be used to make a frontend. Actually any language able to talk with D-Bus can work, and the planned Kde frontend will be made with C++.

Here is a global Diagram of the architecture:
Salut à Toi: Global view

The frontends

Wix: the desktop frontend

Wix is the reference frontend, it is used to test implementation of features. It is based on wxPython. It's intended to be a classical desktop frontend, which should work everywhere. In the future, it could be change its interface for a more experimental one.

Primitivus: the console interface

Primitivus is for console lovers. It is based on Urwid, and the interface is more worked. I had to make several widgets for this frontend, so I eventually put them in a separated library: urwid-satext (Urwid's SàT extensions), I hope they can be usefull for other projects.

primitivus_copie_fichier.png

JP: the command-line tool

JP is a swiss knife, it can be used in many ways. It can be use to easily send file: I spend most of my time in a shell, and it's often annoying to have to go in thousand dialogue boxes just to send a file, furthermore if I am already in the good directory. With jp, I can just type:
jp file mycontact@example.org
and I plan to use a more friendly interface like "jp file nickname".
In addition, jp can send a whole directory by compressing it, accept multiple files without having to accept each time, or send the output of an unix command. It can be used as a powerfull scripting tool, e.g. to notify you when something happen on your server.
In the future, it should gain lot of features like sending microblogs, or managing roster.

jp.png

Libervia: the web frontend

I have waited to make this frontend to start the communication about SàT. Libervia is close to what the fashion wants to name "social network", but with a big emphasis on privacy and user respect; it clearly wants to be an alternative to the massively centralised commercial services. It's entirely made in Python, thanks to pyjamas, with is a Python port of GWT.
There are many thing to say about pyjamas: group centred right management, clear interface, use of widgets, unique input box, visual indicator to show who will be able to read your message, etc.
All of this is shown in a video (in French, but I'm pretty sure it's understandable without the sound, any help to make subtitles welcome):

This video is under Creative Common BY-SA

In addition, a technical demo is online: http://www.libervia.org . Please don't pay any attention to the ugly appearance, we are working on it and it should be really nice looking soon.

Libervia, as the whole SàT project in linked to a social contract, see below.

libervia_prototype1.png

Some things you can do with SàT

Here are some stuff you can do with SàT:

  • Use your e-mail client (MUA) to read and send your messages: XMPP manage "normal" type message, which are heavy messages pretty similar to e-mails (with a subject and a body). This messages are often managed really basically by XMPP clients, but this job could be done by feature-full stable and well-known e-mail softwares like KMail, Thunderbird, Mutt, Roundcube, etc. So, 3 extensions have been made: one to manage a Maildir box, one to manage an IMAP server, and one to manage a SMTP server. Theses extensions allow to connect most of e-mails clients to SàT, and use them to send message to your XMPP contacts, receive messages from them, or even send message to standard e-mail network throught an SMTP gateway. I think XMPP is an excellent candidate to be used as an alternative to e-mail.
  • Microblogging: SàT manage microblogs (only in Libervia so far), not only in the popular classical public way, but also with access restriction through roster-based group access. For example, if you have all you family members in the group "family", you just have to enter "@family: Salut à toi la famille" in the input box, and only the member of your family will be able to read this message. If you want to publish this for everybody, just enter a double @, like this: "@@: my global public message". With this, not only all you contacts will be able to read your message, but even people you don't know as it is public (on the online demo, you can see them through http://www.libervia.org/blog/your_nick).
  • receive multiple files from one contact without having to individually accept them: jp, the command-line tool, allow (among other things) to automatically accepts files, or to send a full directory at once by making a tarball with it.*
  • Nothing to do with XMPP, but an extensions allow to send message to a Couchsurfing account. There is a way to make lightweight XML interfaces for plugins: that allow to make a plugin which will work with all frontends; the couchsurfing plugin was just an excuse to try it.
  • Play French Tarot: I have made a French Tarot game (a card game extremely popular in France), which is playable on the desktop with Wix, in text-mode with Primitivus, or in a browser with Libervia. It was a test in the idea to make a general card game XEP, any people interested in cards games for XMPP can contact me.

Games

Games are an important part of SàT. The following stuff are planned:

  • Generic card games engine: the Tarot Game was an implementation test of a card game. I'd like to take profit of this experience to make a generic XEP, wouldn't it be nice to play your favourite card game through your favourite XMPP client with your friends ? If you are too far to play on a real table of course :)
  • I'd like to do the same think for board games, and a Xiangqi game is planned (Chinese chess)
  • A quiz game is planned in the very short term, probably for next release
  • on the long term, everything can be made, even maybe real-time games

wix_tarot.pngprimitivus_tarot.png

Social contract

Maybe the most important point of all the project: a social contract has been made, and show the principles that SàT and people involved in it follow. It can be read here: http://www.libervia.org/contrat_social.html, but it's only available in French so far.

Licences

  • The SàT backend, Wix, Primitivus and jp are under GPL v3+
  • urwid-satex is under LGPL v3+
  • Libervia in under AGPL v3+

What's next ?

I have reached the point I wanted to build the foundations of the project, and make it credible. Now I need to stabilise everything, clean and re-factor several parts of the code, remove all the ugly Q&D hacks, finish half-made things, etc.
It's the perfect time to give a hand :)

But new features are planned on the short time, mainly picture sharing and quizz game.

You want to help ?

All the tools needed for contributions is here (wiki, bug tracker, mailing list, mercurial repository).
The project use many really interesting stuff like Twisted, Wokkel, Urwid, Pyjamas, etc. It can be a good way to discover them and improve you skill, and I hope give them some contributions.

The help I need:

  • developers ! The project begin to be too big for me alone. In particular, I need people to port SàT on other architectures (*BSD, Android, Mac OS X, Windows, etc.). Only portable technologies have been used, so it should ask a reasonable amount of work.
  • tester: SàT should work with most browsers, most platforms, most XMPP server, etc.
  • Graphic designers: many things to do: icons, design, etc. Somebody just started to help me on this point, that means that the aspect should improve quickly.
  • CSS designers, Libervia should offer different kind of presentations
  • translators
  • donations: if the project succeed, would you make some donation ? Should I take some time to have a donation system ?
  • ...

If you are interested, the first thing is to subscribe the mailing list: http://lists.goffi.org . I hope to have around 10 peoples to start to use it seriously.

Conclusion

This post is only an overview of Salut à Toi, and I think the potential is very big. I strongly believe in the community, and I hope I have interested you enough to have a hand :)

I finish with two videos showing the project (the third one is linked above), but they are in French. Any help to make subtitle for them welcome.

This video is under Creative Common BY-SA

This video is under Creative Common BY-SA

mardi 18 janvier 2011

Recevez et envoyez vos messages XMPP/Jabber avec votre lecteur de courriel grâce à Salut à Toi !

Le courriel est un outil extrêmement pratique, mais qui souffre de plusieurs défauts majeurs. Par exemple, il est très facile de faire de l'usurpation d'identité (e-mail spoofing): juste en changeant les paramètres de n'importe quel lecteur courriel, vous pouvez faire croire que le courriel que vous avez envoyé vient d'une autre personne, une banque, ou autre. C'est une technique très utilisée par les pirates du dimanche pour avoir un mot de passe (en se faisant passer par exemple pour une banque et en disant que le mot de passe a été perdu) ou les spammeurs (une technique courante est d'utiliser votre propre adresse pour tenter de berner les filtres anti-spam).

XMPP/Jabber ne souffre pas de ce problème: les serveurs sont chargés de vérifier que l'émetteur d'un message est bien celui qu'il prétend être.

Or, XMPP définit un type de message, "normal", qui est très proche du courriel classique: il dispose d'un sujet et attend une réponse. Ces messages sont gérés par les clients classiques (c'est dans la norme de base), mais souvent de manière relativement basique.

Voulant gérer correctement ces messages avec SàT, je me suis dit qu'il me faudrait beaucoup trop de travail pour arriver au niveau de fonctionnalités d'un client courriel (ou MUA) correct. Aussi, je me suis dit « Pourquoi ne pas tout simplement réutiliser ces clients ? ».

Et c'est ainsi que j'ai développé un petit serveur courriel qui permet de déléguer la charge des messages de type "normal" à votre client courrier usuel (KMail, Mutt, Thunderbird, Roundcube ou que sais-je d'autre). L'idée est que la messagerie instantanée (messages de type "chat", "groupchat" - salon de discussion -, etc) reste affichée via les interfaces usuelles (Wix/Primitivus), et les messages normaux soient stockées par SàT et gérés par votre client courriel. C'est un pas vers le remplacement du courriel vers un protocole qui a de nombreux atouts.

Quelques raisons qui me font penser que XMPP/Jabber peut remplacer avantageusement (et pratiquement de manière transparente) le courriel:

  • les identifiants jabber (JID) sont similaires aux adresses courriel
  • si une passerelle courriel est disponible côté serveur, on peut utiliser aussi le réseau courriel normal, la boucle est bouclée :)
  • l'usurpation d'identité (spoofing) n'est (théoriquement) pas possible avec XMPP (les serveurs se chargent de vérifier ça)
  • Jabber n'est (pour le moment) pas touché par les messages indésirables autant que le réseau de courriels traditionnel
  • les serveurs XMPP sont souvent plus stricts à l'inscription, et il est plus difficile d'envoyer un message anonymement, pas de relai ouvert: une bonne protection contre le pourriel
  • vous pouvez configurer un compte XMPP pour ne recevoir des messages que depuis quelqu'un de connu (dans votre liste de contacts - roster list- )
  • les connections entre les serveurs Jabber sont chiffrées
  • Toutes les fonctionnalités du courriel (accusé de réception, message HTML, etc) sont soit déjà disponibles sur XMPP, soit peuvent l'être avec une extension
  • ...

De plus, il me semble peu probable qu'une adresse jabber ( ex.: errico@caserte.it ) et une adresse courriel similaire appartiennent à 2 personnes différentes. Il me semble tout à fait possible par la suite que SàT envoie automatiquement le message à la bonne adresse: d'abord tester si l'adresse XMPP existe, et dans le cas contraire envoyer via une passerelle courriel. Quitte à faire une petite bidouille syntaxique pour spécifier si on veut envoyer à une adresse Jabber ou à un serveur de courriel. L'avantage le plus évident d'une adresse courriel est sont côté standard: tout le monde ou presque en a une. Avec XMPP et ses passerelles, la transition entre messagerie courriel et Jabber est possible et quasi-transparente.

Les considérations techniques maintenant

Les serveurs utilisés sont IMAP v4 et SMTP: ce sont des protocoles que pratiquement tous les lecteurs de courriels connaissent. IMAP a l'avantage de permettre une synchronisation avec SàT (y compris l'état du message: est-ce qu-il est lu ? Est-ce qu'on y a répondu ?), et permet d'envoyer des notifications en temps réel de l'arrivée de nouveaux messages. SMTP est utilisé pour l'envoi de messages, c'est tout simplement le protocole le plus utilisé, et ça fonctionne bien. Les identifiants et mots de passes utilisés sont ceux du profil SàT à utiliser (identifiant: nom du profil, mot de passe: mot de passe du compte jabber). Les ports par défaut sont le port 10143 pour IMAP, et 10125 pour SMTP, j'ai pris soin de prendre des ports utilisables sans les droits root, et qui n'ont pas d'utilisation connue.

Les messages sont sauvés dans une boite de type Maildir , idéal pour l'archivage et l'utilisation avec IMAP. De plus, de très nombreux outils existent pour faire à peu près ce que vous voulez avec ces messages. La boîte se trouve dans votre répertoire SàT personnel: ~/.sat/[nom_du_profil]/Maildir

Pourquoi faire ça côté client (SàT) et non côté serveur XMPP ? Déjà au niveau sécurité c'est clairement un plus: le serveur IMAP est local, pas besoin d'ouvrir un nouveau port et donc une brèche éventuelle sur un serveur public plus sujet aux attaques, et une simple règle iptable (pare-feu) interdira les connexions en dehors de votre machine. Ensuite, il faudrait élaborer une XEP, et attendre qu'elle soit implémentée et répandue dans les serveurs. Et puis, j'ai pu faire ça rapidement (merci Twisted), et SàT permet de choisir d'utiliser ou pas cette fonctionnalité (grâce aux extensions), pourquoi s'en priver ? Un des buts de SàT est justement le prototypage rapide d'idées de ce genre...

L'installation

Si vous voulez essayer ça, installez la dernière version de développement, les détails sont sur le wiki.
Sur une *buntu, vous pouvez faire (en console):
sudo apt-get install python-pip python-dev mercurial
sudo pip install "hg+http://repos.goffi.org/sat/"

Évidemment, tout ceci est en développement: il n'est pas encore possible de créer un dossier avec IMAP par exemple, et y'a des tas de petites bricoles du genre qui vont s'améliorer avec le temps. Mais ça permet déjà de se donner une idée.

PS: petite précision: j'utilise parfois XMPP, parfois Jabber. XMPP est le nom du protocole utilisé par SàT (ce qui lui permet de communiquer avec d'autres logiciels similaires), et Jabber est le nom du réseau global qui utilise ce protocole.

samedi 9 août 2008

Un petit script de transcodage

Un petit post pour dire que j'ai retrouvé un script que j'avais écrit il y a deux ans pour transcoder une vidéo utilisant un codec non lisible par VLC dans un fichier mkv. Vous pouvez le télécharger à ce lien: http://www.goffi.org/public/telecha.... Ca peut toujours servir...

Au passage j'ai retrouvé d'autres projets entamés mais non fini, dont je m'occuperai peut être à moyen terme. Pour le moment j'ai un projet qui me tient à coeur depuis un moment que je me suis décidé à commencer, j'en parlerai plus précisément si je ne l'abandonne pas avant qu'il soit utilisable :). Je suis désolé pour ceux qui utilisaient le driver SP2500, l'API du kernel change en permanence et je n'ai pas le temps ni le goût de le maintenir. Si un jour je n'ai que ça à faire je le recoderai en userspace, mais je ne promets rien et de toute manière ça ne sera pas de sitôt.