tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tsp-devel] suggestion pour core.common.TspStreamReader etcore.commo


From: Stephane GALLES
Subject: Re: [Tsp-devel] suggestion pour core.common.TspStreamReader etcore.common.TspSes sion en Java
Date: Wed, 11 May 2005 10:21:45 -0400
User-agent: Internet Messaging Program (IMP) 3.2.5

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.

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"
>
>
>
>


--




reply via email to

[Prev in Thread] Current Thread [Next in Thread]