Reprise du message précédent :
Comme quoi une bouteille peut mettre plusieurs années avant de revenir

Bon, je digère mon repas, et je vois ça après

Je vois ça...
Reste à voir ce que vont en faire les nouveaux !

grmpf
 
c'est bien la seule de mes idées de projets qui aie autant de succès
 
allez, tiens, vais peut-être m'y remettre moi aussi
 
-- edit : le souci, c'est que j'ai plus de site/server pour l'héberger

MagicBuzz > Comme si c'était difficile de trouver des hébergeurs gratuit.

Qui font du .NET ouais
 
(bon, ok, y'en a aussi pour .NET mais bon )

q: dans la RFC de Mara's Dad, il est écrit que les messages doivent être transférés xmlencodés (en tout cas pour son implé à lui):

Dans celle de rawcut, rien d'indiqué.

Faudrait standardiser ça histoire que ce soit propre, je propose que les messages sont envoyés sous forme brute et que c'est à chaque plage d'htmlencoder/xmlencoder son truc à l'affichage, c'est pas logique de transférer des messages encodés et il peut très bien y avoir des petits malins qui décident de poster des messages pas encodés (donc si pré-encodage on va avoir un mix de plages vulnérables et de plages qui double-encodent parce qu'elles encodent en entrée et en sortie)

q2: comment savoir si le serveur d'en face implémente ou pas le protocole étendu? On lui balance un message? Mais les messages du protocole étendu n'ont pas d'ack

Ce serait pas plus simple de bouger le protocole étendu sur un truc un peu plus RESTful, histoire d'avoir une jolie 404 si c'est pas implémenté plutôt que de continuer sur les paramètres HTTP?

q3: c'est vraiment intéressant de forcer/spécifier le nombre de plages "connues"? Pourquoi ne pas laisser cette limite au choix de l'implémenteur et de juste spécifier que le nombre de plages enregistrées devrait être limité? (en filant une valeur conseillée si besoin)

q4: il y a un conflit dans 3.2 e.g. dans 3.2.1, A envoie needWave à B, puis B envoie newWave à A. Sauf qu'à ce moment là, dans la mesure ou HTTP est stateless A ne sait pas qu'il a fait un needWave, donc il faudrait enregistrer le fait qu'on a fait un needWave, avec l'URL de la plage à laquelle on l'a faite, histoire que ça trigger pas 3.2.2.

De même, il faudrait stocker localement quand on balance un newWave à une autre plage histoire d'éviter d'avoir une boucle infinite de newWave

Je trouve ça pas terrible, ça complexifie super violement le protocole par rapport à la version initiale qui était toute propre et complètement stateless. Faudrait qu'on revoie toute la partie étendue histoire que l'ensemble soit stateless. En fait, il suffirait de faire en sorte que tous les échanges étendus soient des couples (needWave, newWave) comme ça plus de problème (voir fin du post)

q5: enfin, je trouve 3.2.3.3 nul, il n'y a aucun raison pour qu'une nouvelle plage fasse ce genre de recherches extensives, le 3.2.1 est largement suffisant: si une nouvelle plage a beaucoup de traffic elle découvrira vite les autres plages (normal) si elle en a très peu elle mettra énormément de temps, voir elle ne les découvrira jamais (normal aussi), c'est largement plus sympa

Donc pour le protocole étendu, je verrais ça en fix, pour commencer:

Ensuite ce que j'en pense spécifiquement:

• 3.2.2 devrait dégager, c'est laissé au libre champ des implémenteurs et quand une plage ne répond plus je dirais juste de la dégager du pool, rien d'autre, de nouvelles plages arriveront (ou pas, là encore, mais c'est pas un problème) via le mécanisme 3.2.1
• 3.2.3.3 pourrait en fait être remplacée par une séquence de newWave=LOCAL_URL pour forcer l'ajout de LOCAL au pool de DISTANT (puisque c'est stateless DISTANT ne se demande pas s'il a envoyé ou non un needWave) et de needWave pour récupérer une des URLs de DISTANT. On pourrait aussi dégager complètement 3.2.3 et laisser 3.2.1 jouer (mais je trouve l'idée pas mal, ça évite qu'une nouvelle plage n'ait qu'une seule destination en mémoire pour ses 10 premiers messages)

commentaires?

 
Moi je suit de loin, mais en ce moment je croule littérallement sous le boulot, alors je peux vraiment pas me charger.

Au fait, autre question, pour la liste de protocoles qui reviennent du Check, l'ordre importe (genre ordre de préférence niveau serveur, ça serait pas mal ) ou pas?

Et c'est vraiment une bonne ide d'avoir addBottle qui puisse être balancé en get? Ca semblerait plus logique de spécifier la méthode en fonction de l'action (check en get, addBottle en post, needWave en get et newWave et recordWave en post)

@Masklinn > A propos de ton "q2".
 
Actuellement, une requête "Check" se fait avec comme valeur "Plage" :
 
maplage?Check=Plage
 
=> Ceci renvoie avec la RFC initiale la liste des méthodes http supportées. OK.
 
Mais pourquoi ne pas simplement ajouter d'autres valeurs pour Check ?
 
Check=Version
=> Retourne, au format texte en base 10 la version actuelle du protocole supporté : 0 pour celui de Mara's Dad, 1, 2, 3... et -1 pour les protocoles en cours de développement.
=> Si on reçoit une réponse invalide ou incohérente, il faut l'assimiler à 0. (genre si on reçoit "GET" parcequ'un test non nécessaire dans la V0 est présent, on sait que la plage n'implémente que le première RFC. Idem si on reçoit une erreur HTTP : le test est fait, mais l'action inconnue).
 
Ca pourrait pas mal aider pour savoir où on en est non ?
 
Et pourquoi pas un :
Check=Features
=> Et ça renvoie la liste de toutes les actions supportée, suivies de la méthode attendue.

J'aime pas du tout:

• Ca force chaque appel aux fonctionalités étendues à faire entre 1 et 2 appels (1 si la fonctionalité n'existe pas en face, 2 si elle existe) au lieu de 1
• Ca duplique une fonctionalité qui existe déjà en HTTP et qu'on pourrait tout aussi bien utiliser
• Ca impose d'avoir une bonne grosse conditionnelle des familles toute dégueu dans le dispatcher alors qu'avec une table de routage propre on peut complètement séparer les différentes actions sans aucun effort si elles sont sur des URLs différentes, donc ça augmente la complexité du code "client" (du côté qui envoie la requête)
• Ca veut dire que le "serveur" doit trouver un moyen de maintenir en sync les fonctionalités implémentées et le retour de Check et Version, ce qui augmente également la complexité du serveur

Donc au final ça rend l'implémentation plus difficile à tous les niveaux et c'est redondant avec des trucs existants sans avoir aucun avantage

En attendant la V1 de la RFC, je viens de terminer une plage en C#/XML. Reste qu'à trouver un hébergeur pour voir si elle accepte les bouteilles de l'océan
 
J'aurais jamais cru que je serais capable de pondre un bordel pareil pour un truc aussi simple arf
 
Ca m'a presque pris une journée et demie

Bon y'a une RFC qui fonctionne bien ou non ?

Ben non, ya que magicbuzz qui répond à mes commentaires

Parce que la RFC elle définit uniquement un comportement très basique, et y'a que l'implé de mara qui y répond effectivement.
 
Faudrait une réforme. Il faut monter un comité

Ben RFC, ca veut bien dire "Request For Comments", non?
Ben moi, j'attends une nouvelle RFC pour la commenter.

Juste une petite question sur vos RFC, est-ce que la dispo des plages dont dépend la marée est acceptable ou non?
J'ai la sensation que non : ça entraîne la désinscription auto du site en question?
 
Traduit, ça donne, est-ce qu'il y a moyen de faire une plage qui ne serait accessible que lorsque mon ordi est allumé? J'ai envie de tenter defaire une version HAppS, mais je ne sais pas encore s'il y a des hébergeurs gratuits pour ce type de framework, d'où le besoin de mon pc allumé

rawcut a écrit une update de la RFC à la page précédente

yen a déjà une page 10, c'est celle que j'ai tenté de commenter

rawcut dit que c'est désinscrit après 5 tentatives échouées, je pense que ça devrait être laissé à l'appréciation de l'implémenteur

Première page, tu vas sur la plage de Mara's Dad.
Y'a un lien vers une ébauche de RFC version 0. (enfin, lui il l'a appelée XXXX)
 
Ce protocole est très limité, mais pour le moment c'est le seul "standard" qui existe.
 
Reste plus qu'à attendre que les bourgeons de la V1 fleurissent

Dans mon implémentation actuelle, parceque la RFC0 ne dit rien sur le sujet, tu es inscrit à vie.
Je pense que c'est aussi le cas de la version de Mara's Dad : ma plage de 2005 est toujours inscrite... Me souvient même pas en avoir finalisé une
 
 
(désolé, prochain coup je vérifie qu'il n'y a pas eu de réponses avant de répondre dans le vide )

Pas de soucis, vaut mieux trop que pas assez et pour peu que tu ne dises pas la même chose -ce qui est le cas puisque te basant sur l'ancienne rfc-, ça peut être d'autant plus intéressant

Le truc sympa, avec ce système, c'est qu'on peut le dériver : par exemple chacun ajoute une phrase à la bouteille, au passage

je sais, mais faut que je voye les conséquences de ce qui a déjà été dit pour ne pas parler dans le vide.

On lance une bouteille et à l'arrivé c'est un tanker qui s'échoue.

monsieur languedepute!

Ben ça t'empêche pas de commenter sur la RFC ou sur les commentaires, c'est un processus communautaire, rawcut a juste écrit son idée d'extension et réécrit la RFC0

 
Wot ?

Voilà, j'ai me nouvelle plage qui est installée
http://beach.manga-torii.com/beach/Beach.aspx
 
Ca tourne sur une configuration relativement inhabituelle
Debian noyaux 2.6 sous Virtual PC 2007 sous Windows XP Familial SP2
Serveur d'application : Apache2
Environnement d'application : Mono
 
Ca m'a l'air de fonctionner malgré tout
 
Les tests sont les bien venus !
 
Pour info :
- Si je n'ai rien oublié, je couvre la globalité de la RFC0
- La GUI est par contre allégée : on ne peux pas inscrire de plage par exemple. Cependant, une requête POST sur la plage avec des paramètres correct ajoute bel et bien une plage
- J'ai fait quelques tests avec la plage de Mara's Dad, sur laquelle j'ai inscrit cette nouvelle plage. De la même façon, j'y fait référence.
 
A noter que je ne supporte la RFC que d'un point de vue "interfaces". Pour les algos, je ne suis pas convaincu par le système de Mara's Dad, donc pour moi une bouteille échouée est bel et bien échouée. Le seul moyen de la faire repartir, c'est de la renvoyer à l'eau après l'avoir lue.
 
J'espère que vous trouverez l'interface jolie, j'en ai chié pour la faire

Je viens de mettre en place un blog Windows Live au sujet de ce projet.
J'y ai réécrit la RFC 0 de Mara's Dad en y appliquant une légère modification à propos de "addBeach" afin de le rendre plus cohérent avec la définition de "addBottle".
Je ne traite que du protocole, pas de l'implémentation, qui je pense doit rester à la discrétion de l'auteur de la plage.
http://magicbuzz.spaces.live.com/b [...] !265.entry

J'ai commencé à créer ma plage à partir de l'exemple de Mara's Dad.  
 
Pour les marées, je pense que je vais me baser sur un calendrié des marées de manière à ce que les bouteilles puissent repartir plus tard si personne ne passe et que d'autres marées ont on plus gros coefficient. De plus je pense que les aléas de la nature peuvent repousser des bouteilles à la mer (ou les faire disparaitre) comme par exemple les tempêtes. Mais bon, ça fait partie de l'implémentation et non du procotole, c'est donc à chacun de voir comment il veut gérer les bouteilles échoués et tout ce qui arrive aux bouteilles.
 
MagicBuzz > Je pense qu'on est tous d'accord pour le protocole RFC 0 tel que tu le décris, par contre ça serait bien que tu mettes également un exemple pour le addBeach par ce qu'il n'est pas très clair sans exemple.

Je note quand même que j'aime pas du tout l'utilisation du mot "ordre". Ce sont des requêtes, les implés sont libres d'en faire ce qu'elles veulent.

omega2 > J'ai mis à jour la doc avec un exemple pour "addBeach". Seulement, je ne suis pas sûr de ma syntaxe... A mon avis une URI url encodée doit pas ressembler à ça... Si quelqu'un peut confirmer...
 
Masklinn > J'a modifié le billet avec le mot "requête" à la place
 
A noter un truc aussi...
Ma plage ne semble pas répondre correctement à la RFC 0...
En effet, Mono est un peu con, et ne supporte pas le "Encoding" sur une requête "WebRequest".
Du coup je sais pas quel charset est utilisé.
Toujours est-il que lorsque j'envoie un "é" chez Mara's Dad, ou que Mara's Dad m'envoie un "é" il est transformé en "?".
Faut que je trouve un moyen pour faire cet encodage autrement
(Je croyais que par défaut Linux travaillait en UTF-8 )

Je confirme que c'est pas ça. urllib.urlencode me renvoie:

J'vois pas pourquoi t'en aurais besoin
 
Et j'en vois pas de mention sur la doc de HttpWebRequest

Je me disais bien
 

Parceque les chaînes de caractères en C# c'est pas des bytes[] qu'on maîtrise.
 
Je ne sais pas comment C# représente la chaîne en mémoire, et la seule chose dont je dois me soucier, c'est de la façon donc il la lit depuis une application externe et comment il l'écrit.
 
Donc quand je lis une chaîne, depuis un WebResponse par exemple, je dois lui dire dans quel encodage elle est.
Et quand je l'envoie avec un WebRequest, je dois lui dire dans quel encodage je veux qu'elle soit.
 
Mais en mémoire, je sais pas comment il la gère. Et dans tous les cas, lui utilise un encodage par défaut pour lire/écrire les strings si je ne lui dis pas lequel utiliser.
 
Donc là à priori je reçois de l'utf-8, lui il décide que ça doit être de l'ISO quelquechose, et converti ça en mémoire.
 
Et le souci c'est que la transformation inverse ne semble pas réussir à retrouver les valeurs initiales.
 
Enfin je pense.
 
En tout cas ça déconne

C'est pareil en Python ou en Java  

Je fais pas de C#, mais à ma connaissance tu lui balances du byte[] à ton webrequest (via request.GetRequestStream().Write) et tu dis au serveur d'en face quel est l'encoding via Content-Type. Et de ton côté tu sérialises en byte[] UTF-8 via Encoding.UTF8.GetBytes

Ben choppes le responseStream et dis lui explicitement que c'est en UTF-8

Oui c'est ça.
Je dois modifier mon code pour travailler avec des streams binaires plutôt de des strings directement.
 
Verrai ça ce soir.
J'espère en tout cas que les méthodes d'encoding de base fonctionnent, parceque sinon je vais stocker des trucs bizarres dans mes fichiers XML -ce qui ne devrait pas empecher leur fonctionnement ceci dit-
 
En fait à la base j'ai développé avant d'avoir Mono.
Du coup j'ai utilisé les méthodes les plus pratiques du FrameWork, et c'est qu'au moment de la mise en production que je me suis heurté à des limitations de Mono :
- Impossible de faire de la transformation XSL (classe "XslCompiledTransform" n'existe pas).
- Impossible de spécifier l'encoding aux classes WebClient/WebRequest/WebResponse => Donc je ne maîtrise pas la façon dont C# allimente/lit mes flux de type string dans ces classes.
 
Et après quelques bidouilles, vu que ça marchait, j'y ai plus touché Là faut que je retravaille un peu le source pour avoir de nouveau un truc "propre" (si faire se peut, parceque quand on voit mon code y'a de quoi prendre peur... en tout cas moi ça m'a fait peur )

Je viens de lire la RFC de rawcut, et finalement, j'en arrive à la même RFC que MagicBuzz à un petit détail près :
- une plage qui débute se doit de se faire connaitre (d'où le "addBeach" de MagicBuzz) mais également de connaitre d'autres plages. Je propose donc qu'une nouvelle plage reçoive en réponse une liste de plage extrait de la plage où il s'est inscrit. De cette manière, la nouvelle plage ne sera pas ni terminus ni un sens unique (une seule plage connus d'elle) par défaut.

Effectivement, c'est une bonne idée.
 
Cependant, afin de ne pas tout chambouler, je propose que ce soit une RFC 1 (et on va en profiter pour ajouter d'autres choses).
 
L'intérêt de cette nouvelle requête "addBeach", c'est qu'elle reste compatible avec la RFC 0, puisque même si une plage utilisant la RFC 0 reçoit une réponse, elle doit simplement l'ignorer (seules les erreurs HTTP sont sensées être vérifiées).
 
Mais je pense qu'on peut ajouter d'autres choses, telles que Wave par exemple : la plage demande des bouteilles à la plage distante, histoire de faire tourner un peu les bouteilles d'une plage à l'autre. L'implémentation de Mara's Dad prévoit déjà ça, mais c'est au niveau de l'implémentation, pas du protocole d'échange.
 
Je propose donc aussi une requête "Wave".
Exécuté à chaque chargement de plage, en direction d'une plage tirée aléatoirement parmi les plages connues.
En paramètre, n bouteilles (n aléatoire, basé sur un ration du nombre de bouteilles actuellement sur la plage).
En retour, m bouteilles générées suivant le même algorythme depuis la plage distante.
 
On peut imaginer qu'au lieu d'obtenir une réponse, la plage distante lance un wave à son tour, mais c'est un coup à partir dans une boucle infinie entre plages, et provoquer des timeout un peu sur tous les serveurs. A ce moment, il faudrait que la wave ne puisse être propagée plus de o sauts (1 par exemple), en ajoutant un paramètre numérique, décrémenté à chaque appel récursif jusqu'à 0.
 
Plage 1 lance Wave sur Plage 2
Plage 2 lance Wave sur Plage 3
basta.

Paramètre à vérifier évidement, par ce que si on met ne serait-ce que 255, on est mal pour le timeout.

Effectivement
 
Soit le MAX est une constante, genre 5.
Soit on part du principe qu'on autorise qu'un saut, et à ce moment le paramètre est une valeur binaire : 0 ou 1 (déjà propagé ou non)

Ca n'a strictement aucun intérêt