Goffi a écrit 1556 commentaires

C'est SàT qui gère le serveur imap, c'est une extension, tu n'as rien à faire à part configurer ton client courriel.

Oui et non, le problème peut être géré à différents endroits.

Un serveur imap est un serveur de plus à gérer, ce qui implique des complications au niveau sécurité, des ports à ouvrir, la gestion des utilisateurs, etc. Là c'est fait au niveau local, tu peux ne laisser ton serveur accessible qu'en local pour ton client courriel, c'est plus simple et sûr. D'autre part, ça n'implique pas de complication si tu as un accès restreint au net: du moment que XMPP passe, ça fonctionne.

J'utilise aussi SàT comme un terrain d'expérimentation pour les idées que j'ai en tête, et là j'ai pu implémenter ça rapidement, sans attendre la publication d'une XEP et l'implémentation dans un serveur. Rien n'empêche de faire de même côté serveur par la suite.

En fait j'avais déjà répondu à cette question dans mon blog (dont le lien donné plus haut), et j'y explique également pourquoi xmpp peut avantageusement remplacer le courriel.

Bon ben en supprimant les mots de passes enregistrés et en refaisant correctement, ça semble fonctionner finalement.

Désolé pour le bruit...

Je pense que le projet est encore trop jeune et pas assez solide pour ça, l'année prochaine peut être, mais merci de la proposition :).

En clair, il n'est pas encore utilisable comme client principal, de nombreuses choses sont implémentées partiellement, et ça manque de test. Mais je travaille dessus, et la situation s'améliore de jour en jours. J'espère que la prochaine version amènera plus de retour et quelques devs...

Super dépêche, merci.

J'en profite pour laisser une note sur mon projet: Salut à Toi ( http://wiki.goffi.org/wiki/Salut_%C3%A0_Toi ), qui permet d'avoir plusieurs interface (desktop, console, ligne de commange, etc), et quelques trucs sympas comme utiliser son client courriel pour lire les messages ( http://www.goffi.org/post/2011/01/18/Recevez-et-envoyez-vos-messages-XMPP/Jabber-avec-votre-lecteur-de-courriel-gr%C3%A2ce-%C3%A0-Salut-%C3%A0-Toi-! ) .

J'ai une grosse version en préparation, et j'espère pouvoir publier une dépêche à ce sujet d'ici quelques jours/semaines :)

C'est vrai qu'il y en a d'autres.
Aller, j'ajoute:
tag => étiquette
markdown => écrire bas... euh non en fait celui là ça va

Rien à voir avec le contenu de la dépêche, mais je suis étonné de voir « game » au lieu de « jeu » sur un site qui a justement l'habitude de traduire la plupart des termes en français. Là je ne vois pas l'intérêt du terme anglais, il y a une raison particulière pour l'utiliser ?

D'autre part, les outils de traduction offre aussi cette fonctionnalité, ceci s'appelle une mémoire de traduction. Lokalize (KDE) propose ce mécanisme. Je te rassure, nous ne retraduisons pas 100 fois "ouvrir" ;-).

Je le sais, c'est justement ce dont je parle en disant « D'autre part un logiciel comme gtranslator propose des traductions similaires déjà entrées », l'idée c'est « est-ce qu'il y a un outil massif où on peut récupérer des entrées stockées massivement ? » (c-à-d: qu'on ne récupère pas seulement ce qu'il y a dans nos .po, mais dans tous ceux déjà disponibles, y compris dans les autres projets).
Pour le moment (du moins ça se passe comme ça chez moi, donc tant mieux s'il y a une meilleure solution), je traduis une fois « ouvrir », et si je l'utilise 10 fois, pas besoin (évidemment) de le retraduire. Si j'ai un truc genre « ouvrir le fichier » il me proposera ouvrir comme texte similaire, et je peux partir de là (bon c'est bien entendu plus utile quand le texte à traduire est plus long). Mais ce que je voudrais, c'est pouvoir utiliser directement les traductions existantes de « ouvrir », déjà faites pour le projet .*, et disponible dans [0-9]+ langues (et sous licence libre).

C'est une vraie question, dans le sens que je ne connais de la traduction que le classique gettext.

Transifex (que je ne connaissais pas), semble en effet pouvoir répondre à ce genre de cas, mais est-ce qu'il est concrètement utilisé ainsi ?

Tiens cette dépêche me fait penser à un truc:
est-ce qu'il existe un système de traductions libres universel ? Parce qu'en développant mes projets, je me rends compte qu'il y a des tas de choses qui réapparaissent tout le temps, et qui sont pourtant retraduites à chaque fois. Un exemple tout con ce sont les menu: combien de fois ont été traduit "Ouvrir", "À propos", etc ? D'autre part un logiciel comme gtranslator propose des traductions similaires déjà entrées, si on avait une base générale, il serait bien plus facile de traduire l'existant.

Est-ce qu'un tel projet existe déjà ?

Je vous conseille de jeter un œil sur le planet de Kde, les réactions sont intéressantes:
- dédramatisation (en gros « on n'en sait pas assez pour faire la moindre conclusion, circulez y'a rien à voir»): [http://greeneg.blogspot.com/2011/02/qt-nokia-and-internet-ra(...)]
- Nokia utilise toujours Qt, et Maemo est prévu pour des ordinateurs mobiles (le téléphone est juste un fonctionnalité du N900): [http://kamikazow.wordpress.com/2011/02/11/nokia’s-risk-with-microsoft-and-the-“mobile-computer”-loophole/]
- toujours de la dédramatisation: [http://blog.rburchell.com/2011/02/bomb-has-hit.html]
- et ça embauche même: [http://www.thelins.se/johan/blog/2011/02/meego-and-qt/]
- on attend et on verra: [http://www.layt.net/john/blog/odysseus/disruptive_times]

et d'autres que je vous laisse découvrir.

Pour ma part, j'ai bien plus confiance en la communauté qu'en n'importe quelle compagnie, et je suis certain que Qt et Kde seront pris en charge quoi qu'il arrive.

Je parlais de développer du code, Emacs c'est la consommation mémoire qu'il permet de développer

En informatique, le gros du boulot est concentré en ile-de-france, quitter l'ile-de-france revient à se priver de certaines missions intéressantes, voire à faire une croix sur sa "carrière" (même si ce n'est pas une fin en soi).
Oui, c'est sur qu'à Sophia Antipolis il n'y a que W3C, CNRS, INRIA, INSERM, INRA, Air France, France Telecom, IBM, HP, ST, et un bon millier d'autres que je ne vais pas m'amuser à écrire ici... Aucune chance d'y faire des missions intéressantes (faut dire qu'avec le soleil c'est plus dur de rester enfermé devant des écrans).

Mais en dehors de ça, je suis d'accord que la centralisation n'est pas une bonne chose; mais je suis tout à fait pour une amélioration des transports en commun (pouvoir se passer de voiture c'est quand même sacrément agréable).

et tu veux pas faire un dd if=/dev/xxx_clé_miracle of=/blah/fichier_que_je_vais_mettre_sur_un_ftp_public ???

Bon j'ai envoyé un mail directement à l'adresse de contact. L'idée serait de faire un stand groupé XMPP/Jabber avec -si possible- de dév des différents projets (Jappix, Poezio, Salut à Toi, etc). Faut voir aussi ce que les autres dévs en pensent :). En plus ça permettrait que la communauté XMPP se connaisse un peu IRL.

Tiens qui a déjà participé aux RMLL ici ? Comment faut s'y prendre pour tenir un stand pour présenter un projet ? Combien ça coûte ? Ça me plairait d'y participer cette année...

(Merci pour l'offre d'hébergement en tout cas)

Ben ça fait longtemps que ça se fait:
http://www.ietf.org/rfc/rfc1149.txt
http://www.blug.linux.no/rfc1149/
Bon, faut pas être pressé (voir les pings).

Alors ça c'est à féliciter et encourager. Même si je ne suis pas sûr que ça soit efficace sur le long terme (coût, blacklistage), l'idée est excellente.
Bravo FDN

Tout à fait, les ondes radio sont dangereuses en cas de répression.
B.A.T.M.A.N. est capable d'utiliser d'autres moyens, que ce soit un câble (ça se planque), ou de la très haute technologie (transmission laser, autre ?).

Voilà un nouvel appel fort à mettre en place rapidement un réseau décentralisé. Pour le moment, la mise sous tutelle des FAI peut bloquer le réseau, mais des alternatives sont possibles: à regarder du côté de Netsuku déjà cité ici ou du protocole B.A.T.M.A.N., et les diverses tentatives de réseau communautaire (réseau citoyen etc).

Voir aussi l'importance des réseau chiffrés, comme freenet. Bref, c'est maintenant qu'il faut mettre ça en place.

Une seule réponse: http://xmpp.org/extensions/xep-0136.html ;)

Hum, c'est tout à fait faisable de sauver ses contacts du MUA via XMPP (enfin ça dépend du client ce coup ci: IMAP et SMTP c'est standard et géré partout, la gestion des contacts c'est autre chose), mais c'est une idée intéressante à creuser.
Les règles de filtrage, il suffit d'implémenter les scripts sieve qui sont justement prévus pour ça (langage de script standard côté serveur IMAP - ou autre -, c'est déjà géré nativement au moins dans kmail, et je crois qu'il faut un plugin pour thunderbird). Vu qu'il y a des déjà des bibliothèques Python pour ça, il suffit de proposer la fonctionnalité sur http://bugs.goffi.org pour que je m'en souvienne le jour où j'ai un peu de temps libre (c'est pas demain la veille ceci dit ;) ).

Au passage, je n'exclus pas de faire moi même une gestion de messages "lourd" (type courriel) plus tard dans les frontends de SàT, mais c'est surtout que c'est impossible dans l'immédiat (j'ai trop de choses à faire, et je suis seul).

Merci pour les encouragements :)

Le paquet Arch va être disponible très bientôt (il va s'appeler sat-xmpp, sat étant déjà pris): quelqu'un du forum Ubuntu (Wido) m'a proposé d'en faire un et s'en charge donc, et nous avons passé une partie de la soirée hier dessus. Par la même occasion il a packagé sat-urwid qui sont les extensions pour Urwid (bibliothèque console python de type ncurses) que j'ai fait pour Primitivus. D'ailleurs si d'autres se sentent l'âme de faire un paquet pour une autre distro, n'hésitez pas à me contacter pour régler les soucis éventuels (il y a beaucoup de dépendances, ce n'est pas forcément simple).

Pour IRC, outre en effet Poezio déjà cité, Primitivus permet d'avoir le salon en plein écran en console (on peut cache les contacts et les membres du salon en deux raccourcis clavier, on peut même supprimer l'horodatage pour gagner de la place). Côté interface de bureau, je suis pour l'instant dans le très classique (type ICQ avec contacts + fenêtres de conversations), mais maintenant que ça commence doucement à tourner, je vais pouvoir commencer à me lacher un peu de ce côté; j'ai quelques idées en tête, dont un affichage proche d'IRC.
Gajim permet plusieurs types d'interface (type ICQ classique, tout groupé, etc), c'est très proche d'IRC.

Pour ce genre de suggestion, vous pouvez utiliser le bugzilla ( http://bugs.goffi.org ): dans un forum je peux oublier, le bugzilla garde trace, attend une réponse argumentée en cas de refus, et permet de voter pour savoir ce qui est le plus demandé :).

D'où l'intérêt d'avoir un client pour le "message lourd" (mail), un pour le chat, etc. C'est dans cette direction que part SàT, surtout avec ses différents frontends :). Après, xmpp te permet de parler à d'autres réseaux grâce aux transports.

En gros pour un mail:

Client Mail (Thunderbird) ==> SàT ==> Serveur XMPP ==> Transport ==> Tout (XMPP, Mail, SIP, etc).

Pour une messagerie instantané, c'est la même chose sauf que c'est un frontend qui est utilisé au lieu du client mail (Wix par exemple).

Pour envoyer un fichier, tu utilises toujours le même réseau (XMPP) qui peut au final envoyer vers tout (genre par mail), mais tu peux utiliser un frontend plus adapté en ligne de commande, comme jp:

jp fichier.tar.bz2 contact@serveur.ext


Bref, tout passe par XMPP, mais t'utilises une interface adaptée à ton besoin.

Ben en fait XMPP permet déjà ça avec les transports: tu utilises ton compte Jabber, et tu t'abonnes aux transports désirés, et ça y'a rien à faire côté client (à part gérer le protocole des transport - XEP-0100 - correctement :) ).
D'ailleurs le transport mail est une des raisons qui me font dire que XMPP est bien placé comme alternative à celui-ci (cf mon dernier billet cité dans ce journal).

Là ce que je viens de faire, ça permet surtout de déléguer la messagerie "lourde" à des logiciels qui savent déjà très bien la gérer, pour me concentrer sur la partie "messagerie instantanée" (ce qui n'exclue pas que je laisserai sûrement la possibilité de gérer la messagerie lourde dans les frontends plus tard).

PS: sinon pour ce que tu veux, les clients multi-protocole sont peut être plus adaptés ? Kopete gère une bonne partie de ce que tu cites.

Ben en fait ça m'intéresse beaucoup d'avoir aussi les remarques de ceux qui s'intéressent peut être un peu moins à XMPP/Jabber, donc faut pas hésiter hein ;)

PS: merci pour les corrections :)