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

[Eric NOULARD]

Le mercredi 11 mai 2005 à 10:21 -0400, Stephane GALLES a écrit :
> Bonjour,
> 
> Pareil pour moi, si on a besoin de cette fonctionnalité, je dis GO !
> et puis le principe  me paraît bien.
> 
> Pour l'implémentation, on pourra toujours refactorer plus tard si on
> a envie (je n'ai pas non plus le temps de me pencher sur le détail)
> 
> Par contre, je ne pense pas que cette modification devra remonter ou 
> apparaître
> au niveau de l'API 'Simple'. Je pense qu'il faudra que ce soit transparent
> pour elle. Dans l'API Simple on peut partir du principe qu'on va toujours
> utiliser le FIFO. On alors il faudrait en discuter.

OK d'où ce que je disais dans mon mail précédent.
Il faut donner un moyen/API d'accès à la FIFO "implicitement" créee.

> 
> Au fait : je vais être trés absent du forum pendant un bon mois, donc
> ne vous bloquez pas à cause de moi s'il y a une décision à prendre dans
> JTSP
> 
> 
> Steph
> 
> Selon address@hidden:
> 
> > Le principe me paraît bien.
> >
> > Je n'ai pas le temps de regarder le détails d'implem' tout de suite
> > notamment pour comprendre pourquoi la méthode configure est
> > nécessaire.
> >
> > A+
> > Eric
> >
> > -----Original Message-----
> > From:       address@hidden on behalf of
> > CHOQUET, Mathias
> > Sent:       Wed 5/11/2005 1:10 PM
> > To: 'address@hidden'
> > Cc:
> > Subject:    [Tsp-devel] suggestion pour core.common.TspStreamReader
> > etcore.common.TspSes sion en Java
> > Bonjours,
> > Je souhaiterais faire une modification à TSPStreamReader et TSPSession pour
> > les raisons suivantes :
> >
> > La FIFO présente dans TSPSession bufferise les données qu'elle reçoit de
> > TSPDataInputStream. Or j'utilise une IHM qui bufferise déjà les données
> > qu'elle reçoit.
> > J'aimerai donc pouvoir rendre l'utilisation de la FIFO optionnelle pour
> > permettre aux utilisateurs de se brancher directement à TSPDataInputStream
> > en passant par TSPStreamReader.
> >
> > Pour se faire, voici ma proposition :
> > Créer une classe abstraite : public abstract class TspStreamReader
> > implements Runnable
> >
> > Cette classe abstraite aurait en plus une méthode configure :
> >
> > public Configure(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.
> >
> > 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;  }
> >
> > 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.
> >
> > 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.
> >
> > Pour TSPSession, les changements seraient :
> > _Changer le nom du thread  « sampleFifoThread » en « sampleThread »
> > _Ajouter une méthode RequestSampleInit(TspStreamReader)
> > _Enlever l'attribut de classe "TspSampleFifo sampleFifo"
> >
> >
> >
> >
> 
> 
> --
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>