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.