Re: [Tsp-devel] JTSP : le sessionId...

[Eric NOULARD]

Le mardi 29 mars 2005 à 08:19 -0500, Stephane Galles a écrit :
> Hello,
> 
> content que cela te plaise !
> 
> En fait j'ai déjà fait un commit d'un début d'API "simple" n, avec un 
> Jstdout "simple".
> Cela va évoluer en fonction des besoins et des modifications que Eric va 
> faire à la
> couche n-1. Pour l'instant j'ai masqué tout ce qui n'était pas stable 
> dans n-1.

C'est sage car je crains d'être un peu à la ramasse pour mes modifs
N-1 début avril... ce sera plutôt mi-avril j'espère.

[..cut..]
> 
> Ceci étant dit, dans mon premier email je n'avais pas soulevé le 
> problème de l'unicité,
> mais effectivement cela mérite que l'on s'y intéresse
> 
> Eventuellement la question qui peut se poser c'est si le TspConsumer 
> reste instanciable,
> ou s'il devient statique :

Dans mon idée le TspConsumer est instanciable et ferais bien de le
rester à mon goût.

TspConsumer == 1 Tsp Consumer conceptuel  qui peut donc gérer/ouvrir
               +ieurs Session.

Si une appli Java décidait d'avoir 2 consumers dont les cycles de vie
sont réellement différents je souhaiterais qu'elle crée +ieurs consumer
et ceci même si elle pourrait utiliser 1 consumer à +ieurs sessions.


Exemple:
  - 1 consumer 'built-in' mono-session qui alimente des fichiers
  - 1 consumer GUI multi-session pour grapher peinard.

Chacun de ces consumers pourraient avoir des 'propriétés' différentes
(priorité des thread crées, période max admissible, débit max etc...)
Je dis ça comme ça mais gérer des 'propriétés' côté consumer peut
être intéressant, histoire d'empêcher le joyeux drille de demander
à un consumer fichier de cracher 300Mo/s et/ou au grapher un tracé
à 128Hz?
Ces propriétés pourraient être passées au constructeur de TspConsumer.
C'est trés prématurée comme remarque mais le mettrais bien dans le TODO.

> 
> Au lieu de
> TspConsumer tspConsumer = new TspConsumer();
> TspSession mySession = tspConsumer.openSession(url);
> 
> On pourrait avoir :
> TspSession mySession = TspConsumer.openSession(url);
> (openSession est une fonction statique de TspConsumer)
> 
> De ce point de vue, la factory redevient unique effectivement. Mais 
> l'argument pour l'unicité est
> qu'on ne veut appeler Initialize une seule fois
> 
> TspConsumer.initialize(args);
> TspSession mySession = TspConsumer.openSession(url);
> (openSession est une fonction statique de TspConsumer)
> 
> Néanmoins, je ne suis pas un grand fan des état statiques dans les classes.
> 
> Dans l'API "simple", faute de mieux j'ai fais quelque chose comme :
> 
> TspConsumer tspConsumer = new TspConsumer(args);
> TspSession mySession = tspConsumer.openSession(url);
> (j'ai enlevé la fonction initialize, et j'utilise le constructeur de la
> factory)

Je suis d'accord avec ça.
Reste à savoir si on peut créer +ieurs TspConsumer en appelant
donc plusieurs fois l'équivalent d'initialize.
(faut que je regarde le code mais pas maintenant)

Si on peut c'est tant mieux,
si on peut pas ben en attendant mieux il faut faire
d'initialize une méthode de classe privée et static 
(et synchronized) qui teste un membre privé static
boolean histoire de gérer en interne l'initialize.

Cette initialize static serait appelé dans le constructeur
de TspConsumer.


> 
> On verra à l'usage et en fonction de vos retours la dessus.
> 
> Steph
> 
> (et encore désolé pour le spam l'autre jour, j'ai envoyé 2 fois
> l'email. Il va falloir que je pense à m'acheter des doigts)
> 
> 
> Pour la factory, je ne pense pas
> 
> dvp.duf wrote:
> 
> > A priori  faire du TspConsumer une Factory implique de part la théorie 
> > des design patern (si je me rappelle bien...) qu'il soit unique ?
> > Je ne vois pas d'impossibilité pour le consumer dans cette unicité, et 
> > l'API que tu proposea a l'air plutot élégante et bien "object" style.
> > Y++
> >
> >
> > Stephane Galles wrote:
> >
> >> Bonjour, bonjour,
[...cut...]