Re: [Tsp-devel] suggestion pour core.common.TspStreamReader et core.common.TspSes sion en Java

[Eric NOULARD]

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