Hi Gaël, interesting points! I'd say that the change in semantics warrant a separate rpc_data class. But I ahve a question, to help me understand: so far I had the impression that rpc calls would, in the new model, also accept a mixture of the old style parameters and the new style data handles - is that the case? If yes, then we would need to change the parameters for the rpc.call() method in a way that both are accepted. If that is not the case, and you can cleanly distingish both use cases, I don't see a problem with a second rpc.call() method which would overload the original one with a different signature. My $0.02, Andre. Quoting [Ga?l Le Mahec] (Sep 02 2009):

Hello,

As we propose at the OGF'25 (Catania), we worked on the Grid RPC data management API integration into the SAGA API (see joined documents). We tried to adopt the SAGA Look-&-Feel and we propose two different ways for the integration :

- Extending the original saga::rpc::parameter class and adding the missing classes/enumerations for a proper integration. - Adding a saga::rpc::rpc_data class to the API. This class extends the main saga::rpc::rpc overloading the call method.

These two different approaches have advantages and disadvantages. Using a unique saga::rpc::rpc class implies to modify the original class to respect the SAGA Look-&-Feel. For example, the attributes of the orginal saga::rpc::parameter class do not make sense for the sub- class saga::rpc::parameter_data. Moreover, the original saga::rpc::parameter inherits from the saga::buffer class, that should not be used for the parameter_data class (change in the semantic).

The second approach is more easily implementable but the API then contains two different methods to call a service.

Maybe there is a better way to extend the current SAGA RPC avoiding to change the parameter class and the two different methods. Please feel free to send any comments about these propositions.

Best regards,

G. Le Mahec for the GRAAL team.

-- Nothing is ever easy.