[ Serge et moi avons commencé à discuter hors demexp-fr@ de la réalisation de l'interface web pour demexp. Serge s'est proposé pour me filer un coup de main pour sa réalisation, mais je ne suis pas très chaud. On continue la conversation sur demexp-fr. ]
Bonjour Serge, Serge Leblanc <[EMAIL PROTECTED]> writes: > On Sat, 2006-07-08 at 09:56 +0200, David MENTRE wrote: [à propos de la réalisation du protocole HTTP] > Mais pourquoi voudrais-tu refaire ce qui est déjà fait ! > A) Soit on utilise apache en faisant un client demexp cgi, dans ce cas, > on bénéficie des facilités d'apache pour le https, proxy, etc... > > clientweb <-> apache-cgi <-> serveurdemexp. > > B) Soit on utilise le daemon HTTP Ocamlnet de Gerd Stolpmann. > http://ocamlnet.sourceforge.net/manual/refman/Nethttpd_types.html#overview > (personnellement je n'aime pas son approche objet et je ne suis pas sûr > qu'il supporte le SSL). Ah, ok, je n'avais pas compris ton propos. J'ai une nette préférence pour l'interface CGI (ou FastCGI). [ à propos du stockage d'état nécessaire sur un serveur. Je soutiens qu'il faille stocker des choses sur le serveur, Serge non. ] >> D'accord mais dans ce dernier cas l'utilisateur perd tout quand il ferme >> son navigateur. C'est bien pour ça que d'habitude les informations >> d'état sont stockées dans le serveur. > > > Il est nécessaire et souhaitable de tout perdre pour des raisons de > sécurité (le site de ma banque annule bien la session si je ne me suis > pas manifesté au bout de 15 minutes). De plus, lorsque je ferme un bon > navigateur HTTPS, celui-ci efface toutes les informations qu'il a en > cache, etc ... D'accord pour les infos temporaire, mais je continue à penser que des états à long terme sont à stocker dans le serveur, cf. mon scénario ci-dessous. >> Comment réaliserais-tu le scénario suivant ? >> >> 1. un client A se connecte sur le serveur, il voit la question 1, puis >> éteint son PC ; >> >> 2. le lendemain, un client B se connecte sur le serveur, il voit la >> question 1 et ajoute une réponse, vote et se déconnecte ; >> >> 3. le client A se reconnecte au serveur, il voit que la question 1 a >> été modifiée (avec mise en valeur de la réponse ajoutée *par rapport >> au client A*) et vote. >> >> 4. le client B se reconnecte il voit que rien n'a bougé pour lui. > > > Non, car chaque fois qu'il se reconnecte ou demande la lecture d'une URL > le navigateur vérifie si elle est toujours d'actualité et là rafraîchie > dans le cas contraire (même si il y a des proxys entre les deux, tu > peux faire l'essai sur un site blog). Oui, je connais ce mécanisme. Mais je ne comprend pas toujours pas comment tu peux implémenter le point 3 ci-dessus sans stocker des informations sur le serveur, vu qu'il n'y a aucun moyen de stocker des infos côté client, même en Javascript. >> Pour moi, on est obligé de stocker les informations de ce qu'a vu A et B >> sur le serveur pour que ça puisse marcher avec un client web. > > Non. > As-tu réfléchi comment fonctionnaient les sites wiki ? > Je ne vois pas de grande différence conceptuelle entre en client demexp > est un site wiki ou un blog. Oui mais un Wiki ne présente pas un contenu différent en fonction de l'utilisateur : c'est le même contenu pour tout le monde. Et les rares cas où il y a gestion d'un profile par utilisateur, il est justement stocké côté serveur. Pour moi, c'est la grande spécificité de demexp : toutes les informations sur les votes et les questions vues sont spécifiques à chaque utilisateur. > Si il y a besoin d'une gestion précise des écritures au moyen de > sémaphore nous pouvons utiliser WebDav/Delta-V : > http://www.webdav.org/deltav/ > http://www.webdav.org/deltav/WWW10/deltav-intro.htm Amicalement, d. -- [EMAIL PROTECTED] -- Liste de discussion demexp-fr. Pour se désinscrire, cliquer sur le lien ci-après. mailto:[EMAIL PROTECTED]
