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

[Gaël Le Mahec]

Le 22 sept. 09 à 12:50, Andre Merzky a écrit :

>> [...]
>> A possible solution could be to modify the current
>> saga::rpc::parameter class to be an abstract class which is "derived"
>> into two different subclasses: the first one encapsulates a
>> saga::buffer and is similar to the current saga::rpc::parameter and
>> the second one implements the new data handle. But maybe there are
>> other ways to proceed (using an interface ?) avoiding to change too
>> deeply the current rpc::parameter class.
>
> I think that this would be the cleanest solution.
>
> It may be useful to add some rudimentary means for
> inspection to the abstract class, like get_type() which
> would return an enum 'Buffer' or 'Handle' - what do you
> think?  That would also simplify implementations which only
> support one type.

Yes, it is a good idea. We can also maybe add a type for the containers.

So we would have classes like that:

package saga.rpc
{
	...
	enum parameter_type
	{
		Buffer		=	0,
		Handle		=	1,
		Container	=	2
	}

	class parameter : extends saga::object
	{
		/*  private constructor. For SIDL definition, just do not define it.
		 *  For the implementation it should look like that:
		 *  CONSTRUCTOR(in parameter_type type,
		 *				     out parameter obj);
		 */

		get_type(out parameter_type type);
	}

	class buffer_parameter : extends parameter
	{
		/*   We use the same constructor that the previous  
saga::rpc::parameter
		 *   In the implementation it calls the constructor of the inherited  
class:
		 *    	  parameter(Buffer)
		 */
		CONSTRUCTOR (in array<byte> data = "",
						  in int size = 0,
						  in io_mode mode = In,
						  out parameter obj);
		...
	}

	class handle_parameter : extends parameter
	{
		/* In the implementation the constructor calls parameter(Handle) */
		CONSTRUCTOR(in array<int> dim_sizes,
						 in array<uri> input_uris,
						 in array<uri> output_uris,
						 in data_type type,
						 in array<data_mode> data_modes
						 out parameter obj);
		...
	}

	...
}

With these definitions, we have an uniform way to call a service  
regardless to the data type (buffer, handle or container). Moreover,  
the containers can also manage these different types.

> Well, that would make the class concrete (i.e. not
> abstract), but so what?  One could leave the constructor
> private, so that the user cannot accidentically create the
> base class itself...
>
> Just thinking out loud here...

Indeed, I think this is a good way to prevent such a problem.

Gaël.