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

[Gaël Le Mahec]

Hi Andre,

Le 3 sept. 09 à 21:50, Andre Merzky a écrit :

> 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?

Yes it is the case. We tried to preserve a maximum backward  
compatibility and in the ideal implementation the Grid RPC call should  
accept old style parameters as well as data handles.

> If yes, then we would need to change the parameters for the
> rpc.call() method in a way that both are accepted.

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.

> 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.

If there are no fundamental objections to modify the rpc::parameter I  
think it is better to propose only one call() method which manages the  
two different parameters.

Regards,

Gaël.

>
> 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.