[Tsp-devel] Types, vecteurs et XDR

[Stephane Galles]

Hello,

Bon, j'ai remis mon accès Savannah en place.

J'ai commencé à regarder les types multiples, mais il y a énormément
de travail de fond avant même de pouvoir implémenter autre chose
que des doubles.

En partculier :
- Le code actuel est assez 'double-centrique' (bon, c'etait pour 
prototyper...hein...).
la première chose que je vais tenter de faire est de le rendre 
agnostique vis à vis du types

Pour cela :
- il faut que le datapool stock les types en RAW, et que la transformation
'Raw'->'user friendly' se fasse au moment de l'envoi (pour l'instant on 
a un datapool de doubles,
c'est la vie). Je sent qu'on va rigoler là...Vu que je n'ai pas de 
station SUN chez moi
ni de Tru64 (non, non...), va falloir bien tester tout cela après, 
parceque je vais faire péter
quelques alignements (ou alors quelqu'un m'envoi des sous pour que je 
m'achète
un AMD64  :)  ).
- Il faut modifier l'API pour pouvoir causer 'types' au serveur. Pour
l'instant il n'y a rien
A ce propos il me faudrait un copie de la spec. Le download des fichiers
se semble pas fonctionner sur Savannah. Yves ?

De plus,
Si on veut implémenter les vecteurs de types et des types autres que des 
doubles,
il faudrait maintenant utiliser la jolie structure XDR concoctée par 
Eric dans les
specs.

Je crois que maintenant que c'est tout ou rien...donc ma TODO list va être :
- datapool en RAW
- Structure XDR pour la couche de transport (pour autres types user 
friendly, types RAW ainsi que vecteurs)
- API à modifier pour pouvoir demander des choses plus compliquées que 
des doubles.

Mais avant tout je règle le problème de la callback pour Stephane.

Cela convient à tous le monde ? j'oublie quelques chose ?

Autre point : je crois que j'ai perdu une information au passage : qui 
fait le refactoring gdisp, moi ?
si oui, est ce +/- urgent que les types autres que les doubles (ce qui 
va prendre pas mal de temps) ?

Stephane (le trappeur).



DUFRENNE, Yves wrote:

> 1) Des types + évolués.
> =======================
> Comme l'a dit Éric, tous les types simples du C, avec en priorité DOUBLE,
> INT, et STRING, avec une gestion parallèle du signé/pas signé.
> Le plus important étant de pouvoir facilement rajouter un type nouveau
> OKAZOU.
> En plus un type OPAQUE/RAW, qui corresponds à n BTYE, sans aucune gestion
> des indiens. Il peut servir temporairement quand un nouveau type manque, le
> consumer ayant par ailleurs une notion de décommutation du type, ou de
> manière permanente pour des types très complexes (structures à la con et
> autres).
> Une notion de tableau serait intéressante, mais je ne vois pas encore bien
> comment la décrire dans le protocole.
> Notre Stéphane Québécois sera peut-être partant pour cette extension ?
>
>  
>
> > Je pense qu'il faut "un certain nombre" de type de base 
> > 'user friendly' du genre:
> >
> >    byte
> >    short
> >    int
> >    long int (hyper integer en RPC je crois)
> >    double
> >    string
> >    char    (1 seul caracère non signe)
> >
> > à voir comment on gère le côté signé ou non sur les entiers.
> > et il faut absolument un type 'opaque' que l'on peut appeler
> > RAW histoire de s'en sortir si ça colle pas et qu'on veut
> > passer une structure, un objet ou toute autre genre de cochonnerie
> > que TSP ne pourra pas connaitre et qu'effectivement seul
> > les 2 bouts seront capables d'identifier.
> >
> > Effectivement on pourra de ce fait lier certains provider
> > à certains consumer mais ça peut être (très) utile de 
> > vouloir/pouvoir le faire.
> > On peut d'ailleurs imaginer une sorte de mécanisme de 'plug-ins'
> > (static ou dynamique) afin de rajouter des types à la con qui 
> > n'ont rien à faire dans le core TSP.
> >
> > Dans tous les cas il faudrait une méthode SIMPLE pour ajouter
> > la gestion d'un type de donnée dans TSP.
> >
> > On pourrait aussi s'inspirer de lib de passage de message comme MPI
> > qui ne comprends qu'une poignée de type de base + des fonctions
> > de l'API qui permettent de 'construire des types' (MPI_TYPE_xxx)
> > cf http://www-unix.mcs.anl.gov/mpi/
> > ou par exemple pour la construction d'une structure:
> > http://www.mpi-forum.org/docs/mpi-11-html/node55.html#Node55
> >
> > Le principe est qu'on "construit" un type avec
> > les fonctions "MPI_TYPE_xxx" puis on le soumet à la lib
> > avec MPI_TYPE_COMMIT. On peut ensuite utiliser ce type dans
> > les prochaines communications.
> >
> > ET PUIS il y a un truc qui est presque aussi important que
> > la gestion de type multiple c'est la gestion des TABLEAUX.
> > Je souhaiterai qu'on puisse gérer les tableaux de données
> > d'un même type de façon orthogonale au type.
> >
> > En gros il n'y a pas de type Tableau_de_double
> > il y a des doubles dont on peut faire des tableaux ou pas.
> >
> >