September 2009 - gridrpc-wg

Re: [GRIDRPC-WG] [saga-core-wg] Grid RPC data management & SAGA
by Andre Merzky 25 Sep '09

25 Sep '09

Quoting [Ga?l Le Mahec] (Sep 22 2009): > >> But I have 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. 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. 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... Best, Andre. -- Nothing is ever easy.

2 4

Re: [GRIDRPC-WG] [saga-core-wg] Grid RPC data management & SAGA
by Andre Merzky 03 Sep '09

03 Sep '09

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.

1 0

Fwd: [saga-core-wg] Grid RPC data management & SAGA
by Eddy Caron 02 Sep '09

02 Sep '09

I forward this mail, Gaël has some problems with gridforge. Regards, Eddy Début du message réexpédié : > De : Gaël Le Mahec <gael.le.mahec(a)ens-lyon.fr> > Date : 2 septembre 2009 17:25:25 HAEC > À : saga-core-wg(a)ogf.org > Cc : Mailing List for GRIDRPC-WG <gridrpc-wg(a)ogf.org> > Objet : [saga-core-wg] Grid RPC data management & SAGA > > 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. > > -- > saga-core-wg mailing list > saga-core-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/saga-core-wg ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

1 0