[saga-core-wg] Grid RPC data management & SAGA

[Andre Merzky]

Quoting [Ga?l Le Mahec] (Sep 25 2009):
> 
> >Some suggested changes below:
> 
> >>	class buffer_parameter : extends parameter
> >
> >This one should then also inherit saga::buffer I guess.
> 
> For a C++ mapping, it is probably the easiest and cleanest way but if  
> I remember well, SIDL does not allow multiple inheritance. So I  
> avoided to use it.

Oh, SIDL does allow multiple inheritance - and, for good or
for bad, we use it in a number of places already.  Mostly
for interfaces though - but at the end, that is what your
base parameter class provides, right?

For example, the rpc class in SAGA is:

  class rpc : implements saga::object 
              implements saga::async 
              implements saga::permissions



> A solution is then to encapsulate a buffer object  
> inside the buffer_parameter class.
> 
> >>[...]
> 
> >What would a container_parameter look like?  I am not sure I
> >understood that one, yet.
> 
> Ooops, I forgot to give the container class.
> 
> class container_parameter : extends handle_parameter
> {
> 	/* For a container, the dimension size is the size of the
> 	 * container which is increasing each time we add a data.
> 	 * And the data type is "Container".
> 	 *
> 	 * So, the constructor call its parent constructor like this:
> 	 * 	saga::rpc::handle_parameter([0], input_uris,
> 	 *							      
> 	 output_uris,
> 	 *							      
> 	 Container,
> 	 *							      
> 	 data_modes);
> 	 */
> 
> 	CONSTRUCTOR(in array<uri> input_uris,
> 					 in array<uri> output_uris,
> 					 in array<data_mode>
> 						 data_modes,
> 					 out container_parameter obj);
> 
> 	// add a data into this data container
> 	set_data(in parameter data, in int rank);

This should be 'add_data()'?  Or is rank the id of the data
item to be set?


> 	// get a data from this data container
> 	get_data(out parameter data, in int rank);
> 
> 	// add a data at the end of this data container
> 	push_back(in parameter data);
> 	...
> 
> }
> 
> A container is then a "special" handle_parameter which contains a set  
> of parameters (accessible using an index value or push/pop methods).  
> We defined it in the Grid RPC data management document to manage sets  
> of data.
> (We have some use-cases where a service is called with a variable  
> length set of input data and a variable length set of output).

I am not sure I understand the purpose of the container
class, really.  The rpc-data draft I found on GridForge
(http://forge.ogf.org/sf/go/doc15355) does not mention it,
really - could you send me an update, please?


> By using the "parameter" class as the type a "container_parameter" can  
> manage, all the different data types can be stored in the container.

Why is that actually needed on API level?  The rpc call is
getting a list of parameters, right (IIRC, its a vararg in
the original C binding.)  For SAGA, its a vector.  So, that
vector already acts as a container for all parameters.  What
additional functionality would a parameter_container
provide?

Cheers, Andre.

> 
> Regards,
> 
> Gaël.
> 
> 



-- 
Nothing is ever easy.