Reprise du message précédent :

Ca n'a strictement aucun intérêt

Pourquoi ?
 
Parceque le problème avec la RFC0, c'est qu'une bouteille échouée sur une plage reste échouée jusqu'à vitam eternam tant que personne n'a lu le message. Seule l'implémentation peut améliorer le comportement. Je pense que c'est pas plus mal que le turnover des bouteilles soit intégré au protocole.
 
Cela dit, effectivement, c'est pas gênant en soit, mais bon.
 
Pour ce qui est de la RFC de rawcut, je ne vois pas de redondance avec cette proposition, puisqu'il ne parle que d'échanger des uri de plages, pas de déplacer des bouteilles.
 
A noter d'ailleurs que je ne suis pas d'accord avec sa dénomitation "wave". Pour moi toutes ses requêtes sont à renommer en "xxxCurrent ou xxxWaterDraft", puisqu'il parle de liens entre plages et non de vagues.
 
Pour moi la vague c'est une bonne grosse vague qui arrive sur une plage, pose des bouteilles et en reprends de nouvelles, avant de continuer son chemin vers une autre plage.
 
Le phénomène que décrit rawcut tient plus des courants marins, dans la mesure ou se sont les liens possibles entre différentes plages.

Ca en a un : limiter les cimetières (plages qui ne renvoyent jamais les bouteilles qu'elles ont reçu)
De telles plages peuvent exister par ce que personne n'y passe, par ce que le renvoie nécessite une action extérieure qui ne survient jamais (webcron qui disparait par exemple) ...
 
D'un autre côté, c'est vrai que l'esprit de départ n'est pas d'ordonner à une plage qu'elle délivre ses bouteilles à une plage donnée mais qu'elle les fasse suivre de temps en temps à des plages pris au hasard dans sa liste à elle.
 
A la réflexion, l'idée du wave n'est pas mauvaise en soit mais ça serait mieux qu'il serve de tempo de secourt (et à chacun de voir s'il ignore ce signal ne serait-ce que par ce qu'il en a reçu un autre trop récemment) et non pas d'ordre d'envoie à une plage donné.

Et alors?

Ben non, surtout pas, justement parce que chaque plage doit être une boite noire, sinon ça n'a absolument aucun intérêt.

Le protocole définit la communication entre les plages, et le fonctionnement interne d'une plage (comme sa capacité à échouer totalement une bouteille ou non) ne regarde que l'implémenteur, et la personne qui utilise la plage si celle ci est un modèle configurable.

Pour analogiser, le protocole standard concerne les courants entre les plages (y compris leur apparition/disparition) et l'envoi de bouteilles à travers ces courants, l'implémentation concerne les courants locaux à une plage, sa météo, sa géographie... tout ce qui concerne l'entrée/sortie de bouteille et ce qui se passe entre.

Oui, j'avais mal lu ta proposition initialement, c'est pourquoi j'ai supprimé mon post

Très bonne idée

J'vois pas en quoi les cimetières sont des problèmes, c'est bien dans l'idée du truc originel et c'est fun

Ouais, je suis d'accord que les cimetières c'est pas plus mal.
Mais c'est vrai que c'est un peu frustrant pour l'utilisateur de savoir qu'il y a de grandes chances pour que sa bouteille ne soit jamais lue...
 
M'enfin tu me diras, c'est le cas pour une vrai bouteille en fait.
 
Je suis d'accord, l'idée de la requête "wave" n'a rien à faire dans le protocole finalement

Rien ne t'empêche d'implémenter un truc pour poster les bouteilles sur un blog avec AdSense

Ah non, ce que sait l'utilisateur c'est qu'il a aucune idée de ce qui va arriver à sa bouteille

Parce que la plage sur laquelle il lance sa bouteille, ou à laquelle sa bouteille arrive, elle peut très bien renvoyer immédiatement toutes les bouteilles, ou les envoyer à un endroit bizarre, autant que les garder échouées

En plus

Par exemple

Ou de jouer à Jesus :
Jesus III, la multiplication des bouteilles (de rouge).

Je viens de corriger ma plage afin de pouvoir envoyer correctement en utf-8 (le problème se situait au moment de l'envoi).
 
Accessoirement, j'ai mis deux zips en ligne : un pour télécharger la plage prête à l'emploi, et une pour les sources. Comme ça vous pourrez voir l'étendue du désastre

So je viens de lire les différentes interventions. Je comprend tout à fait l'idée que les plages soient des "boites noires", et par conséquent qu'on ne les fasses pas s'échanger automatiquent des plages ou des bouteilles. De fait la rfc0 est alors suffisante et on laisse le choix à l'implémenteur de se faire une plage soumise aux marées, aux réchauffement climatique, à l'invasion des ET voleurs de slips    
 
A ce moment là, on peut simplement s'en tenir à la rfc0 ( et traduire la plage la plus basique possible dans les différents languages), et pourquoi pas proposer par ici différents traitements interne à la plage (sous formes d'algo ou d'implé) pour ceux qui souhaiteraient rendre leur secteur plus "animé".

Ah mais j'ai aucun problème avec l'échange de plages ou la requête de , ça fait bien partie de la communication entre les plages ça

J'ai finis l'implémentation de la plage sauf les formulaires de saisie donc on ne peut pas modifier de bouteilles à moins de faire joujou directement avec les URL.
 
Petite question en passant, les plages elles sont obligatoirement sur un serveur situé sur le port 80 ou on peut les mettre sur un autre port?
 
Pour ceux qui veulent faire une plage à partir du script de Mara, il est à noter qu'il y a une coquille dans le script d'installation, il manque la valeur "plage" dans l'énumération de la table plage_bouteilles ce qui fait que les bouteilles restent toujours à la flotte a moins d'être détruite ou d'aller sur une autre plage.

Ma plage "devrait" savoir se connecter à partir de n'importe quel port, et éventuellement "n'importe quel protocole".
 
En effet, je travaille avec l'URI, et ensuite c'est les libs WebClient/WebResponse/WebRequest qui font le travail, je ne gère donc pas le protocole ni le port, qui sont présents dans l'URI.
 
Je pense que l'implémentation doit effectivement prévoir de tourner avec différents ports/protocoles, puisqu'il n'est pas spécifié dans la RFC quels ports et protocoles sont utilisés. On parle de HTTP (mais ça peut tout aussi bien être du HTTPS), et on ne dit mot à propos des ports, donc je suis parti du principe qu'on devait simplement implémenter HTTP/HTTPS de façon "globale" sans entrer dans ce genre de considérations.

C'est ce que je me suis dit à part que je ne gère que le http pour le moment. Je vérais plus tard pour le https quand j'aurais monté un serveur de test qui le gère.

Bon, si j'ai bien compris :
 
1- La RFC0 (ou RFCxxxx) ou  est pas si mal que ça en fait    
2- Manque juste l'échange d'adresses de plages.
3- Il y aurait un bug dans mon script d'install    
 
Bon, elle en est où la RFC0.1 (ou RFCxxxy) ?
 
Si elle est publiée un jour :
a-Je met mon code à jour (sauf si quelqu'un veux absolument le faire à ma place !)
b-Je modifie ma page pour pointer sur la nouvelle RFC et afficher une liste de plages connue plus dynamique.
c-J'arrête de fumer.
d-Enfin, j'arrête de faire des promesses...

Tout petit le bug, ton fichier d'install est très bien si on veut faire une plage sous-marine (bref une plage sans plage)
Par contre une fois le "bug" corrigé, ça gère bien tous les cas pour ce que j'ai vu.

Salut à tous,
 
Je termine ma version prochainement, quelques remarques - dont certaines peut-être déjà évoquées - pour la prochaine RFC.
 
Au niveau du retour, pour les méthodes addBeach et addBottle j'aurais vu en cas de succès un retour avec dans l'entête un code 200, et en cas d'erreur, une 405 (method not allowed) quand on appelle une méthode inexistante, et une 400 (bad request) dans le cas d'un argument invalide (URL mal formée pour le addbeach, problème d'encodage du message pour addBotlle...).
 
Plus accéssoirement, j'aime pas la casse des méthodes et arguments de la RFC0
Je préfère check=plage à Check=Plage par exemple.

Je suis +1 là dessus

Et je suis +0 là dessus, d'un côté j'aime pas non plus la casse actuelle, mais de l'autre si elle est modifiée ça pète toute les implés existantes

Effectivement.

Etant donné que la gestion des code de retour n'empechera pas le bon fonctionnement global avec des implés existantes, je vais me baser là dessus pour ma plage.

Pour la casse, je me ferai violence.

Edit : tant que je suis dans les remarques pour une future version, je pense pas que ça soit "sain" d'autoriser des requètes de modification de la base en GET. Je n'autorise addBottle et addBeach qu'en post.

Je retombe ici. Mon code doit être quelque part, mais impossible de remettre la main sur la RFC complète.
 
J'ai bien la RFC de Mara, mais il me semblait qu'il existait quelque chose de plus complet (de mémoire un blog Microsoft de MagicBuzz).
 
Et toutes les plages sont down

De mémoire, c'est la RFC de mara qui a servit de référence pour les implémentations des plages qui ont été créé. Il y a eu plusieurs réflexions qui ont été mené mais rien qui n'a permis d'aboutir à une RFC plus complète.
 
Pour ma plage à moi, c'est vrai qu'elle est KO pour le moment. Je ne passe plus beaucoup de temps sur la création de mon site et j'en ai eu marre de devoir renouveller le nom de domaine gratuit tous les mois. Elle reviendra quand elle reviendra mais je peux t'assurer d'un truc : le code de ma plage marche très bien. Par contre je ne peux pas le livrer tel quel, il est basé sur un framework maison que je dois encore modifier en profondeur pour utiliser plus d'élément du zend framework.

ben moi après être passé de XP à Vista, j'ai un peu flingué mon image virtual PC, et elle a du mal à binder mon interface réseau. du coup je peux voir le fichier (source + RFC complètée) mais pas le récupérer pour le moment. vais pas griller un DVD pour un zip de 2 Ko
 
et de toute façon j'ai un autre souci, j'ai testé avec une image XP, et ça déconne à plein tube. je suis au fin fond de la cambrousse connecté à une borne wifi un peu pourrave qui n'arrive pas à attribuer d'IP à autrechose que mon interface réseau de Vista, veut pas en filer une à l'image virtuelle de virtual PC. verrai donc à partir de mercredi si changer de réseau corrige le problème.
 
ps : sinon, comme dit omega2, ma RFC n'est pas une RFC officielle. elle apporte un certain nombre d'évolutions par rapport à celle de Mara, mais elle apporte aussi une limitation. en effet, celle de mara n'implémente pas de version de protocole. hors la version 2 inclut des alternatives pour les paramètres, et de nouvelles fonctions. le seul moyen de rester compatible, c'est donc de partir du principe que si l'action de contrôle de version produit une erreur, alors c'est que c'est une version 1. le seul problème c'est que la gestion des erreurs dans la RFC de mara n'est pas suffisament détaillée pour garantir le type d'erreur en cas d'appel d'une action non supportée, donc on peut croire à une plage v1 alors qu'il s'agit d'une plage vX qui est actuellement perturbée par des problèmes techniques

MagicBuzz > Puisque le sujet est actuellement (re)vivant : est ce qu'il existe encore des plages V1 ou est ce qu'on peut se permettre de sauter directement en Vx sans se préoccuper des problèmes d'incompatibilité avec les plages V1?
S'il n'y a plus aucune plage V1 fonctionnelle, c'est le bon moment de repartir sur de meilleures bases quitte à modifier légèrement ce qu'on a déjà fait.

J'vote pour repartir directement sur une Vx avec un protocole modernisé et buzzwordisé

Trop pluzin

Mes remarques plus haut (Masklinized pour cause de rétro compatibilité) sont du coup plus que jamais d'actualité

Edit : celles-là

405 method not allowed ne doit pas être renvoyé si y'a aucune ressource avec le nom de mandé, c'est uniquement si y'a bien une ressource mais indisponible avec la méthode demandée (ex. GET sur un truc POST only)

Quand un truc n'existe pas, c'est plutôt un 404 qui convient.

Et au passage ça n'empèche pas le corps de la requète de contenir une réponse explicitant l'erreur.

Le problème c'est que le protocole v0 c'est du RPC, donc les gens n'ont pas nécessairement compris que le "method" de 405 c'est pas le "method" de RPC

Si j'en croit la RFC du protocole http 1.1, à mon avis, les erreurs 4xx qui pourraient peut être nous servir sont :
- 403 : Forbidden (Interdit) Accès interdit sans que la raison soit précisé
- 404 : Not Found (Non trouvé)
- 405 : Method Not Allowed ( Méthode non autorisée ) Voir la remarque de 0x90
- 406 : Not Acceptable ( langue ou encodage non géré?) A vérifier si c'est utile
- 409 : Conflict (Conflit) A part si une plage essaye d'envoyer ou rapatrier des message après avoir demandé à ne plus faire partie des plages actives, je n'en vois pas l'intérêt pour un système de "bouteille à la mer"
- 412 : Precondition Failed (Précondition échouée) A utiliser pour indiquer qu'il manque des arguments et donner la liste des arguments manquant (utile pour que le gérant de l'autre plage puisse la corriger ou la mettre à jour)
- 413 : Request Entity Too Large (Corps de requête trop grand ) Si un message est plus long que ce que le serveur peut stocker (Evite de tronquer des messages. A voir si c'est utile)
- 415 : Unsupported Media Type (Format du contenu non supporté ?) A voir. Ne sera utile que si on veut gérer plus tard autre chose que du texte (image?)
- 416 : Requested range not satisfiable (Plage demandée invalide) Là, c'est digne d'une "private joke" Je ne pense pas qu'elle sera utile celle là ... quoi que.

Les seules que je vois pouvant être intéressantes sont 405 et à la limite 415

Disons qu'avant de voir ce qui nous serait utile, faut savoir si on étoffe les specs de la v0.

Idées sur une RESTfulisation du protocole (j'vous avais dit que ça allait buzzwordiser) (en fait c'est un protocole qui n'a aucun rapport, vu qu'on peut repartir de 0)

1. Ressources

• L'entrée dans le service (la racine de la plage), c'est la seule URL qui devrait être nécessaire pour pouvoir communiquer avec une plage
• La collection à laquelle envoyer des bouteilles (depuis une autre plage ou depuis un client externe), fournie par la racine de la plage, aucune raison de la hardcoder.

Le reste peut être formalisé, mais ça ne devrait pas avoir d'impact sur les communications entre les plages

2. Content-Types

a - La racine de la plage

Point d'entrée pour une plage qui veut envoyer une bouteille à une autre plage, je me dis que le HTML est très bien pour ça, mais je ne sais pas si tous les langages ont une librairie de scraping qui fonctionne aussi bien qu'un BeautifulSoup (python) ou un hpricot (ruby), mais en partant là dessus:

Requête:

Méthodes requises (2xy):
GET

Headers:
N/A

Méthodes interdites (405):
Dépend de l'implé

Réponse:
Content-Type:
text/html

Headers:
N/A

Body:
un (ou plusieurs?) élément(s) link avec attributs:

• @rel="send bottle" (ou "bottle send", normalement @rel est une liste de tokens et ici cette liste doit contenir à la fois "send" et "bottle", s'tout)
• @href l'URL à laquelle envoyer une bouteille. Peut être n'importe quel type d'URL (relative, absolue, sur un autre domaine, ...), mais le scheme doit etre http (on va éviter l'envoi par mail pour le moment)

b - Collection de bouteilles

Nécessaire en requête uniquement, la réponse peut être une redirection ou un simple ACK (2xy), avec ou sans body.

Requête:

Méthodes requises (2xy):
POST (cf note 1)

Headers:
x-current-from [optionnel], permet de donner une URL à la plage recevant la requête. Cette URL peut être l'URL de la plage d'envoi, ou l'URL d'une plage dans la collection de la plage d'envoi.
Il est recommandé pour les plages envoyant une bouteille de fournir x-current-from
Il est suggéré que les plages envoient l'URL d'une autre plage (et non la leur) ~10% du temps afin de propager les URLs à travers le système (équivalent au système des "waves" auquel certains avaient réfléchi)
Il est possible de forwarder une bouteille (e.g. ma plage reçoit une bouteille et la renvoie immédiatement) et dans ce cas il est recommandé de laisser le x-current-from d'origine sur la bouteille
Les clients n'étant pas des plages (on peut imaginer quelqu'un qui envoie des bouteilles à une plage depuis un simple formulaire web, ou un client cli/desktop) ne doivent pas fournir de x-current-from

Corps de la requête
C'est la partie dont je suis le moins sûr: à la base je songeais à envoyer le message directement dans le corps de la requête avec un Content-Type text/x-bottle (ce qui impose de setter le Content-Length de la requête), mais je ne suis pas sûr du support des différents outils quand à l'accès au corps d'une requête POST directement (sans passer par les paramètres et "application/x-www-form-urlencoded" ou "multipart/form-data" ). Sans compter que ça complexifie les implés qui veulent fournir la possibilité de poster une bouteille directement depuis un formulaire web.

L'alternative, c'est de balancer du application/x-www-form-urlencoded classique avec un param message et le message dedans.

Dans les deux cas, le message doit être en UTF-8.

Méthodes interdites (405):
Dépend de l'implé

Réponse:
Dépend de l'implémentation (cf intro)

note 1: on aurait aussi pu penser à PUT, mais PUT implique idempotence, donc

• n envois d'une bouteille donnée ne créent qu'une seule bouteille (multiple identical requests should have the same effect as a single request)
• je ne sais pas si ça laisse à la plage la possibilités d'en profiter pour envoyer une bouteille

note 2. il est parfaitement possible que la collection à laquelle envoyer les bouteille soit également la racine de la plage (link[@href=""], ou une URL explicite)

Vous en pensez beaucoup de mal?

Le rel en 2 tokens je suis pas fan, je verrais plutôt un rel=bottleReciever ou un truc du genre.
La plage en html, j'étais pas fan, mais ça devient intéréssant si c'est l'url ou un agent humain peut voir des bouteilles (donc une page web qui a comme particularité d'avoir un/des <link rel="bottleReciever" pour les machines).
Je suis pour l'encodage en application/x-www-form-urlencoded avec param message,ça ouvre le truc aux implés les plus simplistes.

send-bottle alors, ça va mieux?

C'est ça, dans la mesure où toutes les plages d'origines avaient un accès HTML "classique" et où c'est sympa, je me suis dit que les nouvelles ne changeraient pas ça, et qu'utiliser un content-type complètement séparé ne servirait qu'à complexifier le brol.

Donc, je résume ce qu'il faut pour envoyer un message.
 
Etape 1 :
accéder à une page web qui retourne le texte

 
Etape 2 :
Appeler la page à l'adresse "http://monserveur.net/uneplage.machin" récupéré auparavant avec comme paramètre "message" qui contient le texte et comme header un "x-current-from" avec une URL et un  "application/x-www-form-urlencoded".
 
 
 
Si j'ai bien compris le "x-current-from" permet de dire quelle plage je suis. Dans ce cas, je pense qu'il est préférable de ne pas mettre l'adresse d'une autre plage dans ce header là pour les raisons suivante :
- on risque d'indiquer une plage qui n'existe pas/plus/n'a jamais existé ce qui va faire croire aux autres plages que celle là est active
- ça empêche de créer des implémentations capable de vérifier les plages qui sont silencieuse depuis trop longtemps.
- si on fournis des URL "au petit bonheur la chance", on ne saura jamais si une plage est au courant de l'existence d'une autre plage. A mon avis, une URL spécifique (à indiquer avec une autre balise <link> de la première étape) servant à indiquer les nouvelles plages ou à fournir la liste des plages connus sera plus efficace pour une telle propagation.

j'aime pas trop l'idée de se mettre des infos dans de l'html
tout devrais passer pas les headers http

Oui (le header est optionnel)

Non. Ou plutôt pas exactement. Il permet simplement de propager des adresses de plage (donc de "créer des courants" d'une plage à l'autre), l'utilité de base c'est de fournir son adresse à des plages qu'on connaît mais pas uniquement.

Je ne vois pas où est le problème.

Non.

C'est fait exprès.

Sauf que
1. C'est beaucoup moins marrant
2. Ca force à créer un second canal d'information alors que l'existant est très bien
3. Ca génère un comportement greedy (les implés sont obligées d'aller se chercher des plages, je trouve pas ça logique)

REST est basé sur des ressources et des hyperliens. Un header HTTP c'est pas un lien. Je suis parti dans une optique d'une API RESTful (à noter que l'api proposée ici est loin de remplir tous les critères de Fielding, mais bon...)

 
La page web retourne pas forcément exactement ce texte, ça peut être une page complète ou tu affiche des bouteilles ou ce que tu veut, elle doit juste contenir le <link...>.

ah oui j'avais raté cette interprétation. À noter également que les "@" sont des sélecteurs d'attributs xpath pour indiquer que ce sont des attributs et non des éléments, ils n'ont pas à être présents dans le source (l'élément n'est rien de plus qu'un élément LINK html parfaitement standard)

Donc un document possible serait:

<html>
    <head>
        <!-- stuff here -->
        <title>whatever</title>
        <link rel="stylesheet" type="text/css" href="css/default.css"/>
        <link rel="send-bottle" href=""/>
        <script type="text/javascript" src="js/default.js"/>
    </head>
    <body>
        <p>Aucune bouteille échouée :(
        <a href="writeMessage">Envoyer une bouteille</a>
    </body>
</html>

J'aime bien ce qui s'est dit. Une chose cependant, à propos de la note 2 du pâté de Masklinn, je pense que ça devrait être le comportement par défaut. Sous-entendu que la RFC devrait définir le comportement le plus simpliste et dans ce cas, l'url de soumission est la racine de la plage.

Évidemment, pour permettre d'avoir une url de soumission différente, il faut un moyen de le donner (et je trouve la méthode sympa), mais si on autorise ça même à titre d'option... Bin il faut quand même vérifier si on est bien dans le cas par défaut, donc quand même lire la balise "optionnelle" (optionnelle dans mon cas de figure). Le serpent qui se mort la queue.

Je pense que je suis aussi clair que le café qui est devant moi là. En substance, je dis juste que l'URL devrait être le seul truc non seulement à connaître, mais qu'on ne devrait pas avoir à en savoir plus dans le comportement par défaut.

Edit : pour l'utilisation de PUT au lieu de POST également. Je jette un œil sur ce que ça implique.
Edit 2 : Ou pas.

Du même coup, si j'ai bien cerné la spec, PUT est pas valable dans notre cas puisque pour ajouter une bouteille foo, il faudrait le faire à partir de l'url /bottles/foo par exemple, et non pas notre url générique de soumission.

En effet, il ne devrais y avoir qu'une url de soumission de bouteille (message), accessible en POST, avec le header optionnel spécifiant l'origine de la bouteille.
ce que cette url fait en GET, on s'en fout (ca pourrait même être une 405 (plage de galet où personne à envie de venir))

Non.

Non plus, pour aussi bien la raison que tu indiques (la balise sert également à indiquer que l'URL est bien le point d'entrée d'une plage) que le fait que ça encode des informations d'URL dans la spec, si Roy Fielding était là il te balancerait par la fenêtre.

Et ça n'a rien de "simpliste" comme comportement, ça a au contraire des implications fortes (ça empêche un point d'entrée statique qui dirige vers une CGI en C). Le gain est faible, on perd en clarté, on perd en flexibilité et on perd la dynamique URL-based. Ca m'emmerde déjà de pas avoir réussi à encoder les méthodes authorisées dans le lien, je tiens pas à partir sur du RPC alors que je voulais tenter une spec REST.