Reprise du message précédent :
Non mais c'est trés bien !
 
Il faut !
Mais je pense que le choix du language se restreint avec les volonté de portage c'est pour cela.
 
Ensuite mise a part l'hybridation avec bittorrent , le serveur local, le reste n'est que du téléchargement http.
 
Les fonctions sont trés simple dans l'ensemble, amoins que je vois pas la difficulté la ou elle est

 
je trouve le GTK1 encore pire

[ Chatodô ] Python (cours & expl) / Handbook / Apero gratuit
 
Une merguez robert !
 

Faux lire la fin du first post.

Bah si ca fonctionne bien je vous inviterai bien a prendre un pot chez moi
 

En meme temps, c'est ce qui fait tout le charme de la chose, on est pas en prod' quoi

C'est sur.
 
J'aimerai savoir qu'est ce qu'il vous parait flou, exactement

Disons qu'un vrai programmeur commence par decrire son projet en long et en large, etablis un cahier des charges puis trace les grandes lignes du programme, et en fonction de tout ca choisis le langage le plus adapte.  
 
Ici on a juste une vague idee des objectifs.

- comment serons organisés les serveurs ?
- quel(s) protocole(s) seront utilisés pour la communication avec les serveurs ?
- quelle sera exactement la structure des fichiers xml échangés ?
- quels mécanismes seront mis en peuvre pour assurer la mise à jour / propagation des informations ?
- quel(s) protocole(s) seront utilisés pour communiquer entre clients ?
- quels mécanismes seront mis en oeuvre pour garantir l'authenticité des oeuvres ?

pour le dernier point, c'est une signature GPG et j'en parle un peu sur la mailing list

je préferais le pdf au xml, vous n'etes pas d'accord ?

si on peut faire avec le pdf autant qu'avec le xml comme ciler semble le dire ; le pdf me semble également un bon choix

Pas tout a fait autant, le XML est completement flexible. Mais en matiere de texte(+images), le pdf est bien adapte. Disons qu'avec el pdf, on prends un risque quand a l'evolutivite du systeme.

les fichiers xml auxquels je faisais allusion étaient les fichiers contenant les infos sur les sources et les documents, comme décrits dans le handbook. Pour le format des documents eux-mêmes, si j'ai bien compris il n'a aucune importance en fait.

Ca serai cool le xml, on pourrai mettre un interpreteur a la sortie mais ca serai abuser des fonctions.
 
- comment serons organisés les serveurs ?  
 
Il y aura des sereur officiel , qui existent deja et non officiels que les utilisateur pourront creer.
 
- quel(s) protocole(s) seront utilisés pour la communication avec les serveurs ?  
 
http
 
- quelle sera exactement la structure des fichiers xml échangés ?
 
Tu parles de quel fichier ?
 
- quels mécanismes seront mis en peuvre pour assurer la mise à jour / propagation des informations ?
 
Comme decrit dans le handbook, un mode "viral" a chaque fois qu'un utilateur se connecte il telecharge les base de donné et fusionne avec la siennes, si il y a des doubles, il prend celle qui est la plus récente.
 
 
 
 
 
 

Bitorrent ayant été écrit en python, je ne pense pas qu'il sera difficl d'intergre torrent.

effectivement jy est pensé

Je suis en train de lire ton handbook, je trouve ce projet de plus en plus interressant.

Je voulais dire concrètement : strcuture des répertoires, noms des fichiers, etc.
 

les fichiers dont tu parles dans le handbook, contenant les adresses des sources, les descriptions des fichiers, etc.
 

Développe : quelle est la nature des messages échangés, comment y répondre, et surtout comment réagir quand un serveur n'est plus disponible ?

srcadr.xml contient plusieur adresse de serveur.

la strucutre des fichiers xml est décrite dans le handbook non ?  
 
Sinon pour la structure des rep serveur, c'est un peu abordé au travers des exemples de structure xml.

Le crash de hardwarefr a détruit la réponse je la reécrit.
 
 

 
Donc le problème c'est que je voulais que les bibliothèque soit simple a rajouté donc je voulais pas qu'il y ai une normalisation des repertoire. En fait les repertoire reste comme ils sont chez les biblio qui s'ajoutent a nous, et deviennent ce qu'elle deviennent pour les nouvelles, le fichier bookscr.xml contient toute les adresses des oeuvres directement comme décrit. Ensuite le nom de fichiers est celui que les bibliothèque leurs donne au depart, et resteront grace/a cause de la signature numerique qui evitera d'avoir plusieur fichiers avec plusieur nom de la même bibliothèque.
 
 
 
 

 
J'ai fait une brève description d'uin contenu de l'interieur d'un fichier xml mais je ne suis pas champion en xml donc ce n'est pas parfait.
 

 
Le mode viral implique que lorsqu'un utilisateur se connecte a un point source il telecharge les fichier xml de ce dernier (peut être gzippé ensemble) et fusionne les fichier pour mettre a jour les donnée oeuvres/serveur. Et le point source, si il n'a pas deselectionner l'adresse peut aussi le faire.  
 
Le programme doit verifier si le serveur repond plus pendant une durée determiné par le point source (durée inclue dans le fichier infosrc.xml) et si il répond plus au dela, il le supprime et informe les point source et utilisateur connecté a lui.
 
La vrai question sur le mode viral est : est ce que le fichier doivent être des listing brut (liste qui s'ajoute et se mette a jour directement et au programme de verifier) ou informatif (xml avec des balise <add> et <remove> qui informerai le programme quoi faire plus simplement)
 
Les deux peuvent être possible.
 
Voila
 
Frederick

ps on a perdu l'adresse des cours xml

ca vous derange pas cette façon de distribuer le handbook ?  
des commentaire ?
 
(une nouvelle version va sortir, nous avons dans notre équipe maintenant une personne trés compétente sur des sujets qui nous manquait)

 
 
Le site final se trouvera ici normalement :
 
http://drfreuderick.celeonet.fr/chatodo/  
 
Je pense que je m'acheterai un nom de domaine histoire de faire un peu plus serieux. Je recommande au passage cet herbergeur de qualité qui est la version payant de webdynamit

bonjour j'écris suite au message de l'un des membres de notre équipe, qu'il a accepté que je copie.
 

Drapeau.
J'ai pas encore tout lu mais ça a l'air sympa
 
EDIT : je n'aurai probablement pas le temps de vous aider, mais je serais un des premiers bêta-testeurs.

Merci

UP pour le nouveau handbook

Je vois lol

drapal Je reviendrais plustard !

Un petit up pour les nouvelles carateristiques.
 
Comme je disais sur la mailing, je me demande de plus en plus si le plus simple ne serai pas de reprendre un client P2P dont le contenu serai en fichier gzip possèdant les informations pour le système de recherche, l'oeuvre et une signature numerique; le tout mis avec le système de sac de clef.
 
Qu'en pensez vous ?

Up pour le nouveau modèle

[/etc/init.d/Education_Nationale start]
 
Ce serait compatible avec le logiciel BCDI?
Il faut savoir que ce logiciel équipe 95% du marché de colléges/lycées en France. Nombreux client aussi dans des biblio/méditahéques.
Info sur le truc ici: www.ac-poitiers.fr
Ce serait cool qu'il puisse (tout du moins) importer les bases de BCDI
 
[/etc/init.d/Education_Nationale stop]

Oui j'avais pensé,
 
Le problème c'est que les fiche BCDI n'apporte pas de contenu proprement dit mais on peut situer les oeuvres geographiquement ca pourrais être interressant

Bonjour a tous j'aimerai savoir comment ce projet ne pourrai pas sucité l'envie a des personnes de mettre des fichier illégaux comme des film ?

Tres simplement qu'il faut passer pas une bibliothèque pour pouvoir mettre un fichier.
 
Au debut je pensais que chaque personne pouvait partager ses fichiers mais en fait au fur et a mesure je me suis aperçu qu'ils existait beaucoup de biblithèque ou de contenu tres diverse, du moins assez pour pouvoir faire office de "Instance".
 
Je préfère valorisé le contenu. Ce qui n'empèche pas que le système reste P2P et que donc les utilisateurs peuvent partager la bibliothèque en question.
 

 
"MA" version de Neti étant à l'abandon, je veux bien contribuer à un projet libre si cela se fait...