Reprise du message précédent :
Je suis plutot de l'avis de Lorill, mais c'est vrai qu'un serveur central simplifierait beaucoup de choses
 
edit: c'est aussi ce coté poétique qui est enlevé avec le serveur qui est dérangeant. Selon moi le serveur ne représente plus le concept de "plages" représenté par les sites

 
On pourrait meme imaginrt que la bouteille connaitrait sa propre histoire, c'est a dire les serveurs qu'elle a parcouru avec la date ...
 
Ca pourrait être sympa, des bouteilles ayant passé sur des sites qui n'existent plus .. a long time ago ...
 
ps : a ce moment la, il faut mettre la fin de vie de la bouteille au moment ou elle sera lue.

je me suis un peu mal exprimé concernant la centralisation
 
pour moi le serveur central servirait à
 
- créer les bouteilles (pour le controle minimum) et les faire partir de n'importe quel point
 
- stocker les infos concernant les bouteilles (quand une bouteille arrive quelque part, le serveur en est informé, et il garde l'historique)
 
- enfin à gérer et contrôler les sites "points de chute"
 
comme ça on garde le coté aléatoire du trajet, seul le départ et le parcourt sont centralisés
 
ça éviterait que :
 
pleins de gens lachent des bouteilles du même endroit (gros site) et que pleins de bouteilles arrivent au même endroit

[mode usine à gaz ON]
 
tous les sites auraient une petite base qui stocke des bouteilles, avec un tps de presence sur le site aleatoire. Lorsqu'elles partent, elles ajoutent le site (ou plage ) sur lequelle elle a séjourné.  
 
[mode usine à gaz OFF]
 
edit : d'ailleurs, il serait peut etre mieux qu'un serveur central stocke la liste des plages possibles. Sinon, on pourrait perdre definitivement les bouteilles si elles s'echoueraient sur une plage qui n'existerait plus. Mais c vrai que certaines bouteilles se perdent definitivement ... A voir

 
A l'origine, j'ai parlé du serveur central avec webservices pour que tous les clients, qque soit la techno employée, puissent avoir les memes methodes (qui ne sont pas si nombreuses que ca ... creer/afficher/deplacer/detruire une bouteille)
 
mais on peut partir sur d'autres pistes ...

tu pourras faire testeuse

ben, d'ou l'interet de definir un protocole... sans vraiment avoir reflechi loin, je prefere aussi l'idée de "pas de serveur central"

c'est sympa l'idée, je plante mon drapal
 
Perso je suis pour l'idée du décentralisé, un peu comme le net lui-même, un site centralisé serait un gros handicap: qu'arrive-t-il s'il n'est pas joignable? les bouteilles coulent? Non, l'idée d'origine est la plus sympa et poétique à mon sens.

donc si on reprends l'idée de "pas de serveur centralisé", chaque site aurait une liste de sites inscrits (les autres sites peuvent s'inscrire sous forme d'un petit formulaire). Ensuite, chaque fois qu'une bouteille est reçue, 3 choix sont possibles suivant un pourcentage:
- affichage (et destruction?)
- modification/destruction (enlever un bout de texte, quelques lettres ou carrément détruire)
- envoi à un autre site, déterminé au bol parmis la liste de sites affiliés
 
Maintenant est-ce dans l'esprit de garder un historique de la bouteille?

ça serait marrant mais ça rendrait le protocole beaucoup plus lourdingue que le truc tout simple proposé par lorill
 
(qui s'implemente en 5 lignes de php avec la lib curl )

Si on garde le parallèle avec la vraie bouteille de mer, la probabilité qu'elle passe 2x au même endroit est sans doute faible, mais cela reste tout à fait possible. Donc l'historique ne sert à rien me semble-t-il.

l'historique c'était juste pour le coté rigolo de la chose non? histoire de voir par ou le msg etait passé...

ben ça dépend, oui on peut dire que tel message est passé sur un site donné puis voilà, ça peut se faire en plus du protocole lui-même
 
mais tracer le voyage d'un message, ça va être plus complexe

et puis surtout quand tu balances une bouteille à la mer, tu ne sauras jamais ou c'est passé, c'est pour ca que je posais la question d'un côté plus philosophique

Entièrement d'accord, c'est l'essence même de la bouteille à la mer, tu peux pas savoir par où elle est passée sinon c'est plus vraiment une bouteille à la mer.

juste comme ça en passant, je signale l'existance de XML-RPC que nous sommes très nombreux à avoir sur nos sites web (car les services des blog reposent dessus).
 
Donc une petite interface et hop, en voiture gertrude.

Premièrement, je suis très agréablement que ce projet succite un intérêt. Si j'avais su, j'en aurais parlé plus tôt
 
Je vois que vous avez bien cerné le but du jeu, et que vous défendez avec vigueur le point le plus important : pas de serveur centralisé, une bouteille qui va au gré des marées sans aucun contrôle.
 
Ci dessous quelques points qui je pense poseront des problèmes, donc sur lesquels je pense que les idées les plus farfelues sont les bien venues :
 
- Le principal problème réside au niveau du déplacement des bouteilles. Ce problème en comporte deux en réalité.
1) il est impossible sur la plupart des serveurs de mettre un batch shell qui puisse déclencher le déplacement des bouteilles en transit toutes les x heures. A partir de là, on est certainement tous d'accord, il faudra que ce soit au moment où un utilisateur vient lire une bouteille. Ce système me plaît pas mal, car dans la réalité, les courants poussent souvent les bouteilles vers des zones très protégées, d'où elles ne peuvent repartir qu'en cas de très forte marrée ou de tempête exceptionnelle. C'est exactement le même comportement.
2) comment envoyer les bouteilles en transit aux différents serveurs ? En PHP, je sais qu'on peut faire très simplement une requête "POST" ou "GET" sur un serveur distant. A partir de là, ça semble résolu d'avance... Mais maintenant, même parmis les hébergeurs payant, il n'y en a que très peu qui activent cette option. Deplus, en ASP par exmple, il n'existe pas de fonction toute faite. Et je sens pas trop un hébergeur accepter l'installation d'une DLL afin d'avoir un objet capable de le faire, et encore moins accepter qu'on fasse un shell.execute !
A ce moment, je ne vois plus que le navigateur de l'utilisateur. Seulement, on va avoir du mal à lui faire faire envoyer 25 bouteilles en transit comme ça. Surtout s'il a IE, il va trouver très suspect ls "tac" que va produire son navigateur à chaque envois.
 
- Ensuite, il y a un autre problème de taille : si ce projet remporte un certain succès, des personnes vont inscrire leur site, puis déinstaller le module. A ce moment, on va se retrouver avec des liens morts. Il faut prévoir un système permettant de supprimer des serveurs la liste des URL qui ne sont plus valides. Je pense qu'un envois avec accusé de réception qui plante 5 fois de suite peut suffir. Par contre, il faudra trouver un moyen pour faire en sorte que le serveur puisse récupérer de nouvelles adresses partenaires afin de remplacer ces sites. Sinon, on risque de se retrouver avec des sites isolées, ou des groupes de serveurs isolé. J'ai un peu réfléchit à la situtation : lorsqu'on supprime un serveur, on s'adresse à un des serveurs opérationnel, et on lui demande de nous envoyer l'url d'un des serveurs qu'il connaît, et qui est oppérationnel. ca risque d'être un peu lourd, mais ça semble être la solution la plus viable. Ensuite, il faut aussi prévoir les flux bi-directionnels : lorsqu'on reçoit une bouteille qui provient d'un site qu'on ne connaît pas alors il faut l'ajouter à la liste des serveurs connus. Ca commence à faire destraîtements complexes hein ?
 
- Et au final, gérer le spam. Le spam peut survenir pour deux raisons :
1) Une personne génère 1000 bouteilles d'un coup en réussissant à passer à travers notre protection anti-flood.
2) Une personne vient de lire un message sur un serveur qui est peut fréquenté, qui hébergeait par exemple 5000 bouteilles.
Là y'a de quoi plancher sur le problème je pense. Ca serait bête de mettre en péril les relations webmasters/hébergeurs parcequ'un site envoit et reçoit par moment plus de 5000 hits en 10 secondes

 
Une chose m'inquiète cependant, sous quel format seront stockées les bouteilles, si on exclu le fait de les centraliser sur un serveur ?

bah ça c à chacun de faire comme il le sent, on s'en tape; l'important c de respecter le protocole qd elles sont transmises

j'ai une autre idée :
 
on edite un de ces vieux post (tres tres vieux en fait) puis on attend ,  
 
 
vu le nombre total de topic sur le forum ben ya gere de chance que se sera lu
 
parfois un mode en aura marre  -> ban -> bouteille perdue    
 
 
 
cetait la petite crise du vendredi EDIT: (quoi samedi deja ??)

ben il est ou le probleme la ?
 

ca y'a pas besoin de se mettre d'accord, chacun peut faire comme il veut. Perso, je m'héberge moi même, donc j'envoie un get.
 
 

pas besoin d'accusé, y'aura une erreur au GET. Soit serveur réponds pas, soit 404    
 

bof... pas obligé. C'est bien si un module le gère, mais c'est pas obligatoire... Une bouteille coincée sur un eréseau de 4/5 sites, ca me dérange pas, vu qu'a tout moment je peux rajouter le mien pour libérer la bouteille.
 

ca, ok, c'est lourd
 

ben faux probleme : tu affiche/envoie maximum 1 bouteille a la fois...

perso je pense pas que le but soit de faire transiter un max les bouteilles avant qu'elles soient lues. le transit doit être totalement aléatoire à mon sens
 
edit: fôte

ben en js, y'aura max 1 seul envoi, donc ca passe...
 

Ben j'aurais pas non plus le 'OK' decrit dans le protocole proposé, donc on peut le detecter. pas besoin de plus.
 

faux. J'en déplace une par une sur mon proto, avec une probabilité de déplacement qui augmente en fonction du nombre de bouteilles, et ca roule  

up

Salut, vu que je suis allé au Japon pendant un mois, j'avais un peu laissé ça de côté.
 
Je voudrais savoir : y'a encore des gens qui s'intéressent au projet ?
 
Si oui, quelques petits points...
 
1) quelles sont vos URL qu'on puisse voir la chose ?
la mienne sera, pour le moment http://test.manga-torii.com
mais bon, pour le moment c'est un peu désert, ça fait rien du tout, et je n'ai pas fait la page de traîtement d'arrivée de bouteille
 
2) en codant, je me suis apperçu qu'il faut absoluement que l'envoi de la bouteille sur un site distant soit assynchrône. En effet, si la bouteille génère le déplacement d'une autre bouteille sur le site distant, alors le chargement de la page de confirmation va rester bloquée pendant ce déplacement, et ainsi de suite... On peut vite imaginer rester bloquer pendant 10 minutes le temps que la propagation des bouteilles aboutisse sur le non déplacement d'une bouteille ou la perte d'une bouteille. Il faut donc rendre la main à la requête appelante aussitôt la requête envoyée, sans se préocuper de la réponse. Je suis actuellement bloqué là dessus (cf. mon post à propos d'ASP.NET).

le lendemain du message j'avais une implémentation en jsp/servlet qui marchait, mais j'ai du arreter le forum un moment, et la ma consomation est bien ralentie...
 
enfin si ca interesse des gens je peux toujours l'uploader quelque part.

Bah ça m'intéressera dès que le mien marchera à peu près
 
Par contre, je serai intéressé pour que tu m'indiques ce que tu envoies (et de quelle manière) quand tu envoies une bouteille, ainsi que ce que tu attends quand on t'en envoies une (à priori, la même chose )
Ca m'évitera de faire un truc pas compatible avec le tiens

ok bouge pas, je le mets en place, avec spec, demo, et implémentation.
 
lien dans 5 minutes

http://lucane.org/bottles/index.jsp

 
Heu, bonjour les gens !
 
Je viens de découvrir votre projet qui me semble sympa.
 
Sinon, je pense que ton problème MagicBuzz est un faut problème.
Quand un serveur reçois une requête addBottle, il ne cherche pas à la renvoyer tout de suite. Il la stocke chez lui. Le renvoie / affichage / coulage des bouteille n'est déclanché que sur une visite d'un internaute.
Enfin c'est ce que j'avais compris des explications de lorill.
 
Au fait, je viens d'en voir passer une sur lucane.org
Edit : 2 bouteilles ! Ca à l'air d'être bien parti votre truc !

bof... j'ai du rajouter une plage bidon (qui perd donc les messages) pour pas rester avec les memes en boucles.
 
va falloir attendre d'autres plages  

Je vais essayer d'en faire une en PHP...
Peut-être demain, j'ai pas trop de boulôt en ce moment.

j'ai un projet à terminer et après je pense m'y mettre. ca me botte trop cette idée
ps: j'ai fait une bouteille chez toi lorill

Bon, vous penser quoi de mon idée de séparer les événements 'Utilisateurs' de ceux entre 'Plages'.
 
Je pense que c'est pas difficile à faire et que çà évite des boucles infinies de serveurs qui font que se causer.
 
D'autre part, personne n'a parlé du contenu des messages.
Il faut bien sûr préciser une taille maxi en octet pour le protocole, et chaque 'Plage' doit éviter de propager du javascript malveillant. Mais je pensais plus au coté légal de la chose. Est-ce qu'il suffit de mettre un avertissement sur le site comme quoi le webmaster n'est pas responsable des opinions des jeteurs de bouteilles ? J'en doute, mais j'ai pas vraiement d'avis. Sauf que je me vois mal faire le modo sur ma plage, ce qui impliquerai de mettre en quarantaine tous message arrivant, ce qui est hors de question...

d'une part bloquer tout ce qui est non-caractère
ensuite je suis d'accord avec toi, c'est pas à nous de faire les flics! (surtout que le principe de la bouteille sera bafoué).

Heu au fait, heu . . . Bonjour !
 
Et les boucles infinies entre serveurs t'en pense quoi ?

Question :
 
Dans l'implémentation de lorill, quand une bouteille est affichée, elle est ensuite soit conservée, soit transmise, soit coulée. Ce choix étant aléatoire et du ressort du prog...
 
Il me semble que pour que ce soit réaliste, ce choix apartient aussi à celui qui ramasse la bouteille sur la plage, non ?
 
En fait, il peut :
- Ouvrir la bouteille et lire le message, ou ne pas l'ouvrir.
Ensuite :
-Détruire la bouteille
-La renvoyer telle quelle ou en ayant modifié le message.
 
C'est seulement dans le cas d'un renvoie que la Plage décide de son sort( Garder, Couler, Transmettre ).
 
Mais bon chacun fait sa propre implémentation...

lorill, ton implémentaion n'est pas COMPLIANT !
Quelle est l'url pour "addBottle"
Si c'est la même que pour une saisie manuelle, on n'a pas le OK en retour.
Remarque ma plage (en cours) s'en fout du devenir d'une bouteille transmise.
Mais le protocole en parle. Alors si certaines plages veulent implémenter quelque chose, ou simplement pour vérifier qu'une nouvelle implémentation de plage marche, je pense qu'il faut répondre OK...

Ouais mais quand t'envoies une bouteille à la mer (ou que tu lâches un ballon ), même si t'as peu de chances de savoir ce qu'il en advient, t'es quand même bien content de savoir qu'elle est arrivée (le cas échéant).
En fait, ce principe de bouteille me fait 'achement penser au bookcrossing : http://www.bookcrossing.com/ Pas dans l'implémentation ni rien mais juste dans l'idée. Et en plus, là, chaque propriétaire de la bouteille sait où elle a atterri.
'fin ch'ais pas, moi j'trouve ça fun de pouvoir tracer une bouteille ou, à défaut, de pouvoir la localiser à un instant donné.