> Alors explique moi pourquoi l'equipe d'eMule ou des autre client a > prit la paine d'attendre d'avoir un client fonction aussi bien en > upload et en download et de s'étre assurer de ne pas créer de > nuisance via des test sur leur propre micro reseau avent de faire > des release publique ?
Ca je n'en sais rien, cela dit, rien n'indique que les perturbations viennent de mldonkey, le développeur d'Overnet dit lui-même qu'il ne sait pas de quels clients ça vient. Et d'ailleurs, le seul endroit où il est indiqué que des "Rogue clients" dérangent le réseau, c'est dans les news du site d'Overnet. Je n'ai rien trouvé dans les forums (que j'ai parcourus aussi).
> Et pourquoi MLdonkey n'a supporté que le download sur edonkey > pendant des mois alors que d'autre client libre implementer l'upload > et que par leur nature leur code était reutilisable ou reimplementable > ( ouaih l'opencaml ca court pas les rues ) ?
On dirait que tu viens de répondre à ta propre question, Objective CAML ça court pas (encore) les rues. Peut-être aussi que la qualité de l'implémentation n'était pas satisfaisante selon le développeur de mldonkey. Mais je n'en sais rien, en tout cas pas plus que toi.
> Pourquoi MLdonkey est le seul client a integrer des régles > discriminatoir face aux autres client et ce sans aucune raisons ( > limitation a 1/3 de la file d'attente des client eMule ) ?
Je viens de parcourir la mailing-list de mldonkey (oui, j'ai que ça à faire :) et j'y ai vu un message de MLdonkey (le développeur principal donc), qui disait que comme 3 clients supportaient le protocole Edonkey, il était naturel de diviser par 3 les slots disponibles pour que tous les clients puissent coexister. Ca me semble plutôt logique à moi.
> La bonne foie des developpeur de MLdonkey je n'y crois plus, > eMule ni croit pas, personne a par toi n'y croit.
Moi, je ne crois rien, j'essaye de me baser sur des informations vérifiables pour me faire une opinion. Et mon opinion n'est pas encore faite sur le sujet.
> C'est trop facile de foutre la merde et de dire apres, a ca serait pas > pareille si vous m'aviez aider et que le soft été libre, quand on a fait > de l'ingenerie inverse pour se connecter au reseau.
Les développeurs de mldonkey n'ont pas demandé que le soft soit libre, ils ont seulement demandé que le protocole soit ouvert et documenté. Ou qu'en l'absence de documentation, que quelqu'un veuille bien leur expliquer comment ça marche. Faire de l'ingénierie inverse pour se connecter à un réseau, ça n'a rien de critiquable en soi, c'est à la base de l'interopérabilité des systèmes et des logiciels. Tu dirais la même chose si quelqu'un essayait d'implémenter un client MSN Messenger si le protocole n'était pas documenté ?
[^] # Re: MLdonkey version 2.04rc1 est sorti
Posté par Frédéric Lopez . En réponse à la dépêche MLdonkey version 2.04rc1 est sorti. Évalué à 10.
> prit la paine d'attendre d'avoir un client fonction aussi bien en
> upload et en download et de s'étre assurer de ne pas créer de
> nuisance via des test sur leur propre micro reseau avent de faire
> des release publique ?
Ca je n'en sais rien, cela dit, rien n'indique que les perturbations viennent de mldonkey, le développeur d'Overnet dit lui-même qu'il ne sait pas de quels clients ça vient. Et d'ailleurs, le seul endroit où il est indiqué que des "Rogue clients" dérangent le réseau, c'est dans les news du site d'Overnet. Je n'ai rien trouvé dans les forums (que j'ai parcourus aussi).
> Et pourquoi MLdonkey n'a supporté que le download sur edonkey
> pendant des mois alors que d'autre client libre implementer l'upload
> et que par leur nature leur code était reutilisable ou reimplementable
> ( ouaih l'opencaml ca court pas les rues ) ?
On dirait que tu viens de répondre à ta propre question, Objective CAML ça court pas (encore) les rues. Peut-être aussi que la qualité de l'implémentation n'était pas satisfaisante selon le développeur de mldonkey. Mais je n'en sais rien, en tout cas pas plus que toi.
> Pourquoi MLdonkey est le seul client a integrer des régles
> discriminatoir face aux autres client et ce sans aucune raisons (
> limitation a 1/3 de la file d'attente des client eMule ) ?
Je viens de parcourir la mailing-list de mldonkey (oui, j'ai que ça à faire :) et j'y ai vu un message de MLdonkey (le développeur principal donc), qui disait que comme 3 clients supportaient le protocole Edonkey, il était naturel de diviser par 3 les slots disponibles pour que tous les clients puissent coexister. Ca me semble plutôt logique à moi.
> La bonne foie des developpeur de MLdonkey je n'y crois plus,
> eMule ni croit pas, personne a par toi n'y croit.
Moi, je ne crois rien, j'essaye de me baser sur des informations vérifiables pour me faire une opinion. Et mon opinion n'est pas encore faite sur le sujet.
> C'est trop facile de foutre la merde et de dire apres, a ca serait pas
> pareille si vous m'aviez aider et que le soft été libre, quand on a fait
> de l'ingenerie inverse pour se connecter au reseau.
Les développeurs de mldonkey n'ont pas demandé que le soft soit libre, ils ont seulement demandé que le protocole soit ouvert et documenté. Ou qu'en l'absence de documentation, que quelqu'un veuille bien leur expliquer comment ça marche. Faire de l'ingénierie inverse pour se connecter à un réseau, ça n'a rien de critiquable en soi, c'est à la base de l'interopérabilité des systèmes et des logiciels. Tu dirais la même chose si quelqu'un essayait d'implémenter un client MSN Messenger si le protocole n'était pas documenté ?