[saga-core-wg] Grid RPC data management & SAGA
Gaël Le Mahec
gael.le.mahec at ens-lyon.fr
Tue Sep 22 17:39:09 CDT 2009
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.
More information about the saga-core-wg
mailing list