RE:RE: [Tsp-devel] suggestion pour core.common.TspStreamReader e t core.common.TspSes sion en Java

[CHOQUET, Mathias]

Bonjours,

Je crois comprendre le problème de la Fifo. cet attribut est public et on ne
peut pas l'enlever 
puisque les consumers actuels s'en servent.

Moi j'aime bien l'idée de faire de la classe TspSampleFifo une classe
abstraite TspSampleSet 
même si cela fait que certaines méthodes n'ont plus de sens.

Voici ma proposition pour arranger un peu ce problème : 

ceux qui utilisent l'ancienne API avec TSPSessionSampleInit()
------------------------------------------------------------
rien ne change à part que l'on instancie TspSampleSet en TspSampleFifo 
dans la méthode TSPSessionSampleInit().

ceux qui utilisent la nouvelle API avec
TSPSessionSampleInit(TSPStreamReader,TSPSampleSet) 
----------------------------------------------------------------------------
--------------
On demande explictement aux utilisateurs d'instancier leur objet
TSPSampleSet (en 
TspSampleToto par exemple) pour qu'ils soient obligés de répondre aux
besoins de l'API TSPSampleSet.
A mon avis, cela peut éviter des confusions pour les utilisateurs.


Mathias C.

> -----Original Message-----
> From: Eric NOULARD [mailto:address@hidden
> Sent: Wednesday, May 11, 2005 7:15 PM
> To: Devel TSP
> Subject: Re: [Tsp-devel] suggestion pour 
> core.common.TspStreamReader et
> core.common.TspSes sion en Java
> 
> 
> Je viens avec une réponse un peu plus détaillée.
> Sur le principe je suis donc POUR l'optionnalité de la FIFO
> sur les détails d'implem' voilà mon avis:
> 
> > 
> > Pour se faire, voici ma proposition : 
> > Créer une classe abstraite : public abstract class TspStreamReader
> > implements Runnable 
> 
> Oui Ok pour classe abstraite
> TspStreamReader 
> 
> (du coup on refactor l'actuelle en TspFifoStreamReader)
> > 
> > Cette classe abstraite aurait en plus une méthode configure : 
> > 
> > public Configure(TspDataInputStream in, TspGroup[] groups) {
> >     this.in     = in;
> >     this.groups = groups;
> >     stop        = false;
> >     }
> 
> Là je ne suis pas d'accord c'est un constructeur de la classe 
> abstraite
> et pas une méthode. Ce serait donc:
> 
> public TspStreamReader(TspDataInputStream in, TspGroup[] groups) {
>       this.in     = in;
>       this.groups = groups;
>       stop        = false;
> ]
> 
> > 
> > Le constructeur et la méthode « public void readGroup(int 
> i) » serait à
> > implémenter par des classes étendant la classe abstraite 
> TspStreamReader.
> 
> uniquement readGroup.
> 
> > 
> > L'utilisation de la FIFO se ferait par défaut avec la classe
> > TSPFifoStreamReader.La méthode readGroup serait identique 
> et le constructeur
> > serait le suivant : 
> > 
> > public TspFifoStreamReader(TspSampleFifo fifo) {
> >     this.fifo   = fifo;  }
> 
> Non ce serait le constructeur actuel avec un appel au
> constructeur du père plus l'init de la fifo.
> 
> public TspFifoStreamReader(TspDataInputStream in, TspGroup[] groups,
> TspSampleFifo fifo) {
> 
>         super(in,groups)
>       this.fifo   = fifo;
>     }
> 
> 
> > 
> > Du coup, l'utilisateur a le choix d'implémenter ou non sa 
> propre classe
> > TSPStreamReader (par exemple totoStreamReader extends 
> TspStreamReader).
> > 
> > Cette classe serait instancié par l'utilisateur et envoyée 
> à la méthode
> > TSPSession.RequestSampleInit(totoStreamReader)  qui 
> surchargerait la méthode
> > actuelle.
> 
> Ca je suis OK.
> 
> > 
> > Si l'utilisateur ne l'implemente pas, il appelle normallement
> > TSPSession.RequestSampleInit() qui instancie 
> TspFifoStreamReader et qui
> > appelle le configure.
> > 
> > Pour TSPStreamReader, les changements seraient :
> > _Créer une classe abstraite TSPStreamReader en laissant 
> vide readGroup et le
> > constructeur
> > _Ajouter la méthode configure (décrite au-dessus).
> > _Créer une classe TSPFifoStreamReader qui implémente le 
> constructeur et
> > readGroup.
> 
>   Voir mes remarques précédentes.
> 
> > 
> > Pour TSPSession, les changements seraient : 
> > _Changer le nom du thread  « sampleFifoThread » en « sampleThread »
>   Ok pour sampleThread.
> 
> > _Ajouter une méthode RequestSampleInit(TspStreamReader)
>   Ok pour pour ça aussi.
> 
> > _Enlever l'attribut de classe "TspSampleFifo sampleFifo"
> 
>   Ca ne va pas être possible si simplement.
>   Même si c'est pas joli du tout.
>   Les consumers actuels utilisent ce membre.
>   Il faut donc continuer à leur donner accès de façon à ce qu'ils
>   puissent faire maSession.getSamples().getSample() ou encore
>   maSession.getSamples().nbSample()
> 
> La TspSampleFifo pourrait devenir une classe (Abstraite) TspSampleSet
> et le membre publique de TspSession un getter TspSession.getSamples()
> qui renvoie un TspSampleSet dont l'API ressemblera à celle du
> TspSampleFifo.
> 
> Je suis pas très content cette dernière suggestion vu que si
> l'appli a fourni son propre TspStreamReader les méthodes
> maSession.getSamples().getSample() ... n'auront pas de sens...
> 
> Si on veut avoir une session qui offre sur un appel
> 
> TSPSession.RequestSampleInit()
> 
> la bufferisation avec FIFO il faut qu'ensuite l'appli ait
> accès à cette FIFO (ou au mini une API pou récupérer les samples)
> puisque ce n'est pas elle qui l'a crée.
> 
> Je réfléchis à ça et j'y reviens j'attends aussi ton retour/tes idées
> sur ce point Mathias.
> 
> 
> Eric
> > _______________________________________________
> > Tsp-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/tsp-devel
> 
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>

important_notice.txt
Description: Text document