[Tsp-devel] appel RPC mono-argument une autre explication....

[Erk]

Je ne sais pas si vous vous souvenez
mais j'avais posé la question au moment
du rajout des requêtes async_read/write et filtered_info
temps du pourquoi avoir spécifié
des interface RPC avec 1 seul argument qui englobe
toute la requête.

Une bonne réponse de Stéphane Galles avait été
de dire que certains rpcgen  ne géraient pas le multi-paramètre
(d'ailleurs on doit ajouter le -N à rpcgen pour qu'il
 accepte le multi-argument qui est un comportement "new-style")

Du coup les request_filtered_info et autre async_read/write
ont plusieurs paramètres...

Malheureusement,
une autre "bonne" raison qui m'avait échappé et je m'en excuse
justifiait ce choix.

Le dialogue TSP asynchrone a été conçu sous la forme
de request --> answer
chaque request étant une structure qui obtient en retour une
autre structure answer.

En fait chacune de ces structures représente UN MESSAGE
formaté (et encodable en XDR ou autre chose) que l'on souhaite
ensuite envoyer via un canal de commande: RPC ou autre chose....

Avec mes ajouts j'ai mélangé l'encodage des reqêtes avec
l'envoi par le canal de commande, shame on me :((

Cela reprends tout son sens avec un deuxième canal de commande
et encore plus avec le generateur de code en préparation.

Chaque MESSAGE TSP (request ou answer) peut être envoyé
encodé directement sur un quelconque canal de commande qui
l'encodera comme il l'entends.

Je pense que dans la période de refactoring qui se pointe
et qui pourrait nous amener vers TSP 1.0 il serait souhaitable
de rester dans l'esprit du

answer TSP_send_request(request)

On peut même imaginer des versions "minimales" de canal
de commande où l'on implémente qu'UN SEUL APPEL:

encoded_answer TSP_send_encoded_request(encoded_request)

et qui permettrait d'envoyer une requête TSP pré-encodée
(XDR, CDR, etc...)

le canal de commande ne verrait qu'un buffer d'octet
struct encoded_request {
     int             encoded_size;
     opaque    buffer<>;
}

de cette façon rajouter une nouvelle requête ne nécessite
"même" pas la mise à jour de l'API de commande.

On doit "juste" créer (i.e. générer à partir de l'IDL) les fonctions
d'encodage des différentes requêtes/réponses TSP .


--
Erk