[Jderobot] DEBATE -> cambios en el modelado de los interfaces ICE

[franciscomiguel.rivas en urjc.es]

Buenas,
me ha surgido una cuestión que puede ser importante al estar añadiendo  
funcionalidad a recorder/replayer y tiene que ver con la definición de  
los interfaces ICE que tenemos en jderobot.


Os pongo el ejemplo de encoders.ice para que quede mas claro. Encoders  
tiene la siguiente clase:
class EncodersData
   {
   	float robotx;
   	float roboty;
   	float robottheta;
   	float robotcos;
   	float robotsin;
   };

que es justamente lo que devuelve el interfaz:

idempotent	EncodersData getEncodersData();

Para que pueda ser devuelto por el interfaz tiene que estar definido  
como clase, a la que ICE añade varias funcionalidades que nos  
simplifica la vida, el problema es que no podemos definir desde fuera  
una variable de tipo EncodersData, tenemos que utilizar siempre los  
punteros que nos proporciona ICE. Eso para casi todas las aplicaciones  
no es un problema pero para recorder si ya que no "puedo" grabar la  
clase completa, lo único que quiero guardar son los datos en sí, es  
decir, los atributos que estamos añadiendo a la clase desde el  
interfaz ICE. Por ello me tengo que definir un tipo de datos  
intermedio que tenga todos esos datos y hacer una copia "a mano" del  
tipo:

struct encoders{
      float robotx;
      float roboty;
      float robottheta;
      float robotcos;
      float robotsin;
};

y luego hacer un dump de esos datos a un fichero, esto significa que  
si hacemos un cambio en el interfaz para añadir una nueva variable que  
pudiera ser útil en un futuro habría que modificar recorder/replayer  
para que sea capaz de guardarla.

Una opción que puede quedar limpia es separar los atributos de las  
clases y definirlas en conjunto bajo un struct. De esta forma si hay  
algún cambio en el interfaz no afectaría a recorder/replayer ya que  
tira directamente del tipo de datos definido en el interfaz.
Para el ejemplo de encoders el interfaz quedaría como:



module jderobot{

	/* laser information */

   struct EncodersDataStruct
   {
   	float robotx;
   	float roboty;
   	float robottheta;
   	float robotcos;
   	float robotsin;
   };

   class EncodersDataClass
   {
   	EncodersDataStruct data;
   };


   /**
    * Interface to the Gazebo encoders sensor.
    */
   interface Encoders
   {
      idempotent	EncodersDataClass getEncodersData();
   };

}; //module


los cambios que hay que hacer en los componentes con muy poca cosa ya  
que simplemente hay que anidar el acceso a los datos con ->data-> y  
listo.



¿que os parece?
¿se os ocurre otra forma de abordar esto?

un saludo,
Fran.


------------------------------------------------------------------
Laboratorio de Análisis del Movimiento, Biomecánica, Ergonomía y  
Control Motor (LAMBECOM).
Departamento de Fisioterapia, Terapia Ocupacional, Rehabilitación y  
Medicina Física.
Universidad Rey Juan Carlos (URJC).