maitretarot-devel-fr
[Top][All Lists]
Advanced

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

Re: [Maitretarot-devel-fr] (no subject)


From: philippe brochard
Subject: Re: [Maitretarot-devel-fr] (no subject)
Date: 15 May 2002 11:08:04 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Yves Mettier <address@hidden> writes:

> On 14 May 2002 12:39:26 +0200
> philippe brochard <address@hidden> wrote:
> 
> > Yves Mettier <address@hidden> writes:
> > 
> > > Oubliez pas qu'a terme, tout ce qui est commun a tous les clients,
> > > c'est cool si on arrive a le mettre dans libmaitretarot.
> > > Sous-entendu :les fonctions deviennent alors opaques. Optimisez-les
> > > en fonction des besoins!
> > > 
> > Opaque dans quel sens ?
> > 
> > Est-ce que si je passe un pointeur sur une  structure a ces fonctions
> > (player_t *  actuellement) est-ce que ça va ?
> > 
> > un truc du style : player_send_bid (player_t * player)
> >                    player_send_chien (player_t * player)
> >                    player_get_chien (player_t * player)
> >                    ...
> > 
> > Ou alors il faut faire une couche de plus est passer directement un
> > pointeur sur les enchere, sur le chien, et sur la carte a jouer ?
> 
> Il faut un truc de ce niveau, voire d'un niveau plus haut encore.
> 
> > 
> > un truc du style : send_bid (gint * bid)
> >                    send_chien (gint * chien)
> >                    get_chien (gint * chien)
> >                    ...
> 
> Ca, y'aura forcement. Si le programmeur veut utiliser ca, il pourra.
> Apres, on peut rajouter une couche avec ton player_send_bid qui
> utiliserait send_bid en interne dans la lib.
> 
> > Personnelement, je prefere la version avec la structure (sinon, je ne
> > serai pas parti avec elle :) ) pour le cote legerement oriente objet
> > plus facile a maintenir/comprendre : on agit sur l'objet et non pas
> > directement sur les données.
> 
> Faut les deux couches au minimum. On programme en C, donc faut laisser
> le programmeur faire du bas niveau s'il veut. Mais comme toi, j'aime
> l'approche objet, et je suis assez pour.
> 
Oui, tout a fait d'accord :)

> > 
> > 
> > D'un autre cote, est-ce que le client et le serveur ne doivent pas
> > etre completement separes ?
> 
> Pas au niveau du protocole.
> Ceci dit, je crois que tu suggeres implicitement une nouvelle
> bibliotheque, style libmt_client.so. C'est tout a fait envisageable.
> Mais ca rend l'ensemble encore plus lourd a installer.
> 
> D'un autre cote, je ne crois pas que ce soit trop mechant au client de
> trainer la lib qui contient les fonctions de serveur. Quant a
> maitretarot, il n'est pas oriente performances ni optimisation de place,
> donc je ne vois aucun inconvenient a mettre les fonctions du client dans
> une lib commune. A condition bien sur que ca reste commun au projet.
> 
> Note aussi que mettre les fonctions de communication dans libmaitretarot
> permet, lorsqu'on s'y mettra, de modifier le protocole a un endroit
> unique si l'on change le protocole!
> 
Oui, si on fait une bibliotheque il vaut mieux tout mettre en commun,
pour la maintenance du protocole.
Par contre, il ne faudra pas que l'API change, il faut vraiment garder
quelque d'opaque mais fixe.



Philippe




-- 
,-------------------.         ,---------------,----------------------.
| Philippe Brochard |   ...   | address@hidden | http://hocwp.free.fr |
`------------------(_  (. .)  `---------------'----------------------'
-------------------ooO--(_)--Ooo--------------------------------------



reply via email to

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