tsp-devel
[Top][All Lists]
Advanced

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

Re: [Tsp-devel] Faut-il tout casser ?


From: Erk
Subject: Re: [Tsp-devel] Faut-il tout casser ?
Date: Wed, 12 Apr 2006 16:26:30 +0200

Le 12/04/06, DUFRENNE, Yves <address@hidden> a écrit :
>
> Salut à tous & toutes.
>
> Mon message est volontairement provocateur, mais son contenu est moins 
> violent:
> Pourquoi a-t-on encore les répertoires ctrl, ctrl_init, driver, .... et 
> autres nommages exotiques.
> Je propose une nouvelle arbo sous core (qui d'ailleurs serait mieux nommé 
> kernel....)

le 'core' me plait bien, d'ailleur mon dico dit

core = partie centrale
the core issue = la question centrale
hard core = noyau dur

> src/core/provider à la place de ctrl & ctrl_init
> src/core/consumer à la place de driver
> src/core/remote qui stockera le RPC, le XML, le CORBA, et la touille commune 
> de Fred qui fait IDL => génération XML & RPC, structures ...

je suis d'accord pour
src/core/provider
src/core/consumer

par contre je rajouterais
src/core/common
où les structures communes aux parties provider et consumer
(du core) trouveront leur place

pour
src/core/remote

je serais plus pour
src/core/if ou src/core/interface

il y aura effectivement des sous-répertoires par 'interface'
rpc
xmlrpc
corba

et à la racine d'interface un fichier 'tsp.idl'
qui regroupera toutes les définitions du .x actuel
en plus d'exhaustif
(notamment dans la définitions des codes d'erreur)

Pour l'outils de parsing de l'IDL + génération de code
je pense qu'il ne devrait pas être dans l'arbo TSP car:
    1) il sera utilisé peu souvent , uniquement ceux qui
        développe un nouveau canal de commande
        ou suite à l'évolution de l'API TSP ce qui n'est pas si
        courant.
    2) les fichiers qu'ils génère devraient être ajouté
         à la conf pour que ceux qui font "seulement"
          ./configure && make && make install
         n'ait pas à l'installer
    3) Il est écrit en Java et ça risque de dérouter
        les développeurs C ne ne pas pouvoir compiler
        parce qu'ils n'ont pas de 'java'
     4) on pourrait vouloir changer cet outil sans changere l'arbo

Donc pour l'outil de Fred qui fait IDL --> xxxx je pencherais
pour un module de haut biveau autonomes.

--
Erk




reply via email to

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