Bonjour Thomas, Quelques réponses (un peu tardives)...
Thomas Gazagnaire <[EMAIL PROTECTED]> writes: > Pour le moment, on a un serveur officiel, un serveur demo, un serveur > test, etc... Serveur officiel : serveur du projet politique. Serveur démo : serveur « pour rire », l'idée était que les gens pourraient l'utiliser pour poser des questions idiotes ou s'amuser avec les idées derrière demexp. Il s'avère que les gens confondent serveur officiel et serveur de démo (notamment parce que s'était le serveur par défaut). Donc on le supprimera un de ces quatre (en tout cas je vote pour et je pose une question en ce sens dans demexp, et hop !). Serveur de test : serveur utilisé pour le développement quand on fait des choses destructives, uniquement utilisé par les développeurs. > Pour le moment on a aussi plusieurs clients : drupal, interface cgi, > ... Client GTK : pour l'instant, le seul client utilisable. Interface demexpweb.cgi : ma première tentative pour avoir une interface web, reprise et améliorée par Ketty pour son projet. Interface Drupal : autre approche pour une interface web, offre notamment le lien avec des forums (donc la partie débat de l'expérience). > Première question : pourquoi avoir plusieurs serveurs ? Ce qu'on veut > multiplier c'est les bases de données, pas les serveurs, non ? Réponse simple : mon actuel serveur ne supporte qu'une seule base. :-) Ça ne doit pas être si compliqué de le transformer en multi-bases mais dans tout ce qu'il y à faire, ce n'est pas dans les priorité. Mais le code est à toi ! ;-) Fait un patch qui marche, je l'intègre. > Ainsi, si une association veut pouvoir faire voter ses membres sur > certaines question, installer leur propre serveur risque d'être un peu > compliqué (il faut des connaissances assez évoluées en informatique). > Par contre, ils pourraient faire une demande d'ouverture d'une > nouvelle base de données sur le serveur officiel. On a pensé à ça depuis le début et j'aimerais vraiment pouvoir le faire facilement. > Je ne sais pas trop si ce genre de considération a été pris en compte > dans le développement actuel du serveur. Non. Objectif actuel : avoir un proto fonctionnel (y compris la délégation) sans sécurité. Ajouter la sécurité. TWD. > Deuxième question : au niveau des clients, a-t-on le choix du serveur > sur lequel on veut se connecter (par l'intermédiaire d'un panneau de > configuration où on pourrait choisir les différents bases de données qui > nous interessent : l'asso locale qui organise mon quartier, le parti > demexp, la gestion du projet truc-muche). Oui mais pas graphiquement. On peut mettre autant d'URL demexp:// que l'on veut en ligne de commande et ça ouvre autant de navigateurs sur ces serveurs. Il faudrait faire un petit menu qui permette de choisir le serveur à ouvrir et permette d'éditer les paramètres des serveurs, mais je n'ai jamais eu le courage de le faire (Labgtk, c'est pas fun à programmer). À noter que dans le code actuel, il y a un point nul : l'objet pref qui stocke les préférences de l'utilisateur (questions vues et votées, logins) n'est pas partagé entre les différentes instances du navigateur, donc une partie des modifs est perdu. J'avais commencé à corriger ça mais je suis tombé sur un bug d'OCaml 3.08 (sur les objets, cf. archives de demexp-dev@) et je suis bloqué actuellement dans cette version du compilo. Je peux t'aider à bosser sur ça si nécessaire. Discussion à poursuivre sur [EMAIL PROTECTED] > Il ne me semble pas avoir vu ceci pour le moment. Est-ce prévu dans > une évolution future des clients en cours de dev ? Tout est prévu, rien n'est fait. ;-) > Le client pourrait même avoir une interface pour demander à créer une > nouvelle bdd sur le serveur pour un sujet spécifique (avec validation > "à la main" ou autre, voir le point suivant) Validation manuelle, je pense, sinon on pourrait assez facilement faire un denis de service. Sinon, je ne suis pas contre. Pour les deux modifs que tu proposes, il faudrait modifier l'API réseau. Je ne sais pas comment faire ça proprement (cf. ma discussion avec Ketty sur demexp-dev@) mais on peut creuser si tu es motivé. Il y a des choses dans le coin que je voudrais rendre plus clean. > Troisième question : la méthode de validation "à la main" des comptes > sur le serveur est *très* lourde. Pour le serveur web ou le serveur demexp ? Pour la partie web drupal, je suis entièrement d'accord, tant pour l'utilisateur que pour le pov' admin. ;-) La procédure actuelle marche pour 1-2 nouvel utilisateur par jour mais après ça devient ingérable. Pour l'utilisateur, on a proposé un certain nombre de remarques à Augustin. Il ne reste plus qu'à coder tout ça. Pour l'admin, j'ai deux-trois idées qui pourraient simplifier les choses de mon côté, mais là aussi, il faut proposer du code. J'ai pas le temps de tout regarder. ;-) Si tu parles de la partie serveur demexp, il est relativement facile d'automatiser des trucs avec l'interface pydemexp (en Python) qu'a fait Thomas Petazzoni. > Je n'ai pas encore pu tester le > nouveau client drupal parcequ'entre le moment où j'ai réagit pour > demander un compte et le moment où j'ai eu une réponse, le serveur sur > lequel on faisait des tests à changé. Du coup j'ai fait une nouvelle > demande et je n'ai toujours pas de compte sur le serveur test. Le serveur de test et l'interface web on eu quelques soucis, a priori corrigé par Augustin : il est possible que ta demande se soit perdue. > Ce n'est pas une critique du validateur :-) juste que ça me parait un > peu logique que tester l'identité de chacun est lourd, ce qui n'est > pas forcément nécessaire en fonction du but recherché : par exemple, > si on veut utiliser demexp dans un petit projet, on a pas forcément > besoin de connaitre le lieu de naissance et le nom de tout le monde, > et faire des tests sur les IP, les horaires de connection, la > similarité des mots de passe, etc ... peut-être largement > suffisant. Donc, ça pourrait être pas mal, qu'au niveau de la création > d'un serveur, ou d'une bdd sur un serveur, on puisse choisir le mode > de validation des nouveaux comptes : pas de validation (comme pour les > tests par exemple), validation par email (en testant que 2 comptes > n'aient pas le même email), validation par un modérateur qui pourrait > demander des compléments d'information à la personne qui s'inscrit. Je vois que tu as le cahier des charges, il n'y a plus qu'à coder. ;-) > L'idée au final, c'est de simplifier l'utilisation du logiciel : Entièrement d'accord : c'est depuis le début notre objectif. Mais faire un logiciel simple, c'est pas simple ! :-) > - on a unique serveur officiel, avec plusieur bdd. Tout le monde peut > créer une bdd, soit sans aucune vérification, la bdd aura alors un > niveau de confiance faible pour ses utilisateurs, soit en étant validé > par un modérateurn la bdd aura alors une confiance fort pour ses > utilisateurs Dans le cadre de l'expérience démocratique, on en a pas besoin. Pour que demexp soit utilisé par des assos (comme Gulliver), ça serait utile. > - chaque utilisateur utilse un unique client, qui lui permet de choisir > les bdd auquel il veut participer : certaines ont un niveau de confiance > faible, il peut s'y inscrire immédiatement et commencer à voter, à > discuter sur les différents sondage. D'autre un niveau de confiance > fort, il devra envoyé un certain nombre d'information au modérateur de > la bdd (qui peuvent dépendre d'une bdd à l'autre, un petit texte > descriptif pourra être ajouté à cet effet lors de la création de la > bdd). Entièrement d'accord. > Pour utiliser ce client, il n'a qu'UN SEUL login/mot de passe à > utiliser, celui du client, qui est le même que celui du serveur. Pour l'authentification unique, je n'ai pour l'instant pas d'avis. Je n'ai pas eu le temps de me documenter sur le sujet. Mais brut de pomme, j'ai l'impression que si tes différentes bdd sont gérées par des personnes différentes (le serveur demexp officiel, une asso sur le web, un institut de sondage), il serait très difficile voire impossible de synchroniser les identifiants. J'aurais donc tendance à dire : à une base correspond une liste d'identifiants (comme c'est le cas actuellement, cf. participants.ml.nw). > Voilà, je ne sais pas très bien comment situer tout cela par rapport au > gros travail qui a été réalisé jusqu'à présent. Mais il me semble que si > on veut que le logiciel demexp marche, il faut qu'il soit *tres simple* > d'utilisation, aussi bien au niveau du serveur que du client. Objectif initial dès le début. Mais c'est dur ! > Mais bon, j'ai un peu l'impression de dire "il faut faire" alors que > je n'ai pas fait grand chose jusqu'à présent :-) Yaplukamontrercequetuveuxfaire. ;-) Discussion à poursuivre probablement sur demexp-dev@, en anglais. Mon code n'est pas forcément des plus clean, surtout sur le client. Je suis prêt à accepter toute amélioration et nettoyage, pourvu que ça marche au moins aussi bien qu'avant. ;-) Au chapitre des choses à faire un jour : - faire un nettoyage des cookies trop vieux sur le serveur ; - porter sur ocamlnet2, qui supporte notamment les ONC RPC sur SSL ; - utiliser config_file pour ajouter un fichier de config sur le serveur (config des bases, du réseau, des options à mettre ou pas, etc.). Amicalement, d. -- GPG/PGP key: A3AD7A2A David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A -- Liste de discussion demexp-fr. Pour se d�sinscrire, cliquer sur le lien ci-apr�s. mailto:[EMAIL PROTECTED]
