[Tsp-devel] JTSP : le sessionId

[Stephane Galles]

Bonjour, bonjour,

j'étais en train de commencer l'API niveau n  pour JTSP, mais il y a un 
petit
détail qui m'est revenu concernant la notion de sessionId actuellement 
utilisé par
l'API n-1 . Ma remarque est valable à la fois pour l'API niveau n et 
n-1, car il n'y
a pas de raisons de gérer cela différement.

Actuellement le cycle de vie d'une session est le suivant :

TspConsumer tspConsumer = new TspConsumer();
int sessionId = tspConsumer.openSession(url);
TspSession mySession = tspConsumer.getSession(sessionId);
[...]
tspConsumer.closeSession(sessionId);

Autremement dit, l'objet tspConsumer possède une Map
de toutes les sessions ouvertes, et on y accède par sessionId. Puis
quand on veut fermer une session, on s'adresse à monsieur le
TspConsumer

Je trouve cela un peu "forcé". D'une part parceque on est dans un
langage objet, et qu'on a pas besoin d'un objet TspConsumer pour
gérer la destruction de la session, et d'autre part, proposer un sessionId
comme handle ne fait que déplacer le problème, car il va bien falloir
que je mettre ces sessionId dans une Map ou liste à moi, pour savoir
ce qu'ils signifie. Autrement dit, je préfèrerait que l'objet TspConsumer
ne soit qu'une factory et me gérer mes listes de sessionId

Je vous propose donc la chose suivante :

TspConsumer tspConsumer = new TspConsumer();
TspSession mySession = tspConsumer.openSession(url);
maMap.add(maCle, mySession);
[...]
mySession.close();

La plupart des API objet fonctionnent comme cela. Sa création
n'est pas de la responsabilité d'un objet, mais sa destruction l'est.
Exemple classique des drivers JDBC java (object Connection : 
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Connection.html )

En tout cas, pour tester, je vais faire mon API "simple de cette 
maniere", on verra
si on le garde ou pas en fonction des réactions (d'Eric surtout !)