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="throw-bottle" (Edit : modif de la spec') (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
application/x-www-form-urlencoded classique avec un param message et le message dedans.
 
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?

Real life, the best mmo ever !

Tiens sur la partie b-requete-corps, dégager le premier paragraphe, dans le 2e tout enlever jusqu'au MIME, et dans le 3e enlever "dans les deux cas"

=> Ne laisser que

hgwebdir.cgi suxx

 
C'est super facile à mettre en place hgwebdir

Et faudrait que tu changes le readme (ou que tu le dégages), paske le readme rails il intéresse personne

J'ai pas dis le contraire. C'est juste super moche.

Oué. Il faudrait.

La différence par rapport à (ce que j'ai compris) Masklinn, c'est que la partie cliente est simplement une lib du projet (indépendante de rails, donc potentiellement réutilisable pour un Botabeach). L'algo est détenu par la plage, qui appelle au besoin le bouzin d'envoi.