- gridrpc-wg - lists.ogf.org

OGF 28 Report
by Yves Caniou 03 Apr '10

03 Apr '10

Dear All, Thank you for the interesting discussions. Hélas, we hadn't enough time to handle all the topics that we wanted to. Here are a couple of things that we still have to discuss: - What do we decide about the terminoloy and the use of "interoperable" and "compliant"? - Do we go toward an IDL-specification? (BTW, really useful?) - Answer to the "To discuss" paragraph p. 11 of the document. - And what do we plan about the document since it has finished RFC? Furthermore, concerning the interoperability of implementations, I forgot to add some information: One can think of the handle of the data to contain the DM ID, and thus, the DM with who we deal localy can use the corresponding DM implementation if available and if needed to get data. Coming real next: - I have updates the main document to correct some oups (still some to correct in the talks). - Eddy will update the OGF28 documents on the forge (for the moment, current versions available in http://graal.ens-lyon.fr/~ycaniou/Research/GridRPC/) - Eddy will send the document on the SAGA mailing-list (accordingly to a starbuck-coffee-discussion with André) - Hidemoto and I will be able to meet in Tokyo in the next weeks. We'll try to put some information on the list at that moment. Cheers. .Yves. -- Yves Caniou Associate Professor at Université Lyon 1, Member of the team project INRIA GRAAL in the LIP ENS-Lyon, Délégation CNRS in Japan French Laboratory of Informatics (JFLI), * in Information Technology Center, The University of Tokyo, 2-11-16 Yayoi, Bunkyo-ku, Tokyo 113-8658, Japan tel: +81-3-5841-0540 * in National Institute of Informatics 2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo 101-8430, Japan tel: +81-3-4212-2412 http://graal.ens-lyon.fr/~ycaniou/

2 1

Schedule for the GridRPC meeting at 5pm - Room HGB-A 016
by Eddy Caron 16 Mar '10

16 Mar '10

Dear all, OGF'28 GridRPC Meeting. 5pm - Room HGB-A 016. Program Compliance Testing for the GridRPC data management API specification [Florent Chuffart (GRAAL- INRIA)] GridRPC Data Management API Implementations and Interoperability Issues [Yves Caniou (GRAAL - CNRS - INRIA)] Download: http://forge.ogf.org/sf/go/doc15909?nav=1 Best Regards, Eddy ---------------------------------------------------------------------------------------------- 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 ] ------------------------------------------------------------------------------------------------

2 1

Next OGF. Interoperability
by Eddy Caron 06 Mar '10

06 Mar '10

Dear all, In the first version of GridRPC the document of interoperability described the behavior of Grid-RPC through a bench-like to validate the GridRPC implementation. Interoperability Test client code 0.2 https://forge.gridforum.org/sf/go/doc14379;jsessionid=D464228C7398F05ECBDA9… We plan to do a similar work for the version of GridRPC with data management. To be fully interoperable, Yves Caniou open a new thread around this aim. He gave in this document different implementation examples. "We also have to consider a second document to discuss some implementation issues: functions introduced in the API work on some methods and some data, and providing interoperability information could ease protocol interoperability of different implementations. The aim is to either help the interoperabliity implementation design, either to ease the design of some glue to render different implementations able to communicate and exchange data without external help. We already gave such comments and work can begin from those, available in http://graal.ens-lyon.fr/~ycaniou/Research/GridRPC/implementation_examples-… " Best Regards, Eddy ---------------------------------------------------------------------------------------------- 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 ] ------------------------------------------------------------------------------------------------

3 2

Next OGF
by Eddy Caron 07 Feb '10

07 Feb '10

Dear Hidemoto and all, Do you have an idea of the next schedule for the OGF. What do you think about to give two talk around DIET and Ninf very close to the previous one introduced during SC'09 at the AIST booth. Around the recent development about the Cloud computing. And we can open the discussion about if it's relevant to extend the API to a Cloud parameters ? Another proposal, we can give a talk about the integration of the Grid-RPC with data management and SAGA. Another proposal we can design the document about the Grid-RPC data management interoperability. Anybody have another idea or remarks ? Best Regards, Eddy ---------------------------------------------------------------------------------------------- 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 ] ------------------------------------------------------------------------------------------------

4 3

Latest version of the GridRPC Data Management API
by Yves Caniou 13 Oct '09

13 Oct '09

Dear All, Here's the file. Cheers. .Yves. -- Yves Caniou Associate Professor at Université Lyon 1, Member of the team project INRIA GRAAL, LIP / ENS-Lyon 46 Allée d'Italie 69364 LYON Cedex 07 France tel: +33 4 37 28 76 48 http://graal.ens-lyon.fr/~ycaniou/

1 0

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

Some information from OGF'25 to OGF'27
by Eddy Caron 17 Mar '09

17 Mar '09

Dear all, Due to too many parallel sessions (we was in conflict with Cloud session and one around the data management) the GridRPC meeting was very poor. But the SAGA session was very fruitful. We continue the collaboration with GridRPC WG and SAGA WG with a concrete roadmap. We have discussed with Andre Merzky and we plan to update the current GridRPC implementation with the data management feature. The todo list for the GridRPC WG should be the following OGF'26: We conclude the document and we plan to give at least two talks one about this API and the second talks about how we have implemented in DIET (by Gaël Le Mahec) and Ninf (by Hidemoto Nakda). OGF'27: We will present the SAGA/GridRPC (with DM) interface and we plan to provide an implementation of it. Best regards, Eddy ---------------------------------------------------------------------------------------------- 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 ] ------------------------------------------------------------------------------------------------

2 1

updates for document
by Hidemoto Nakada 02 Mar '09

02 Mar '09

All, We will have a session in Italy next month, on Tuesday morning. Please plan your trip so that you can join us. #Unfortunately, I can not make the trip, but Eddy will lead the session. I'm now in Lyon, visiting DIET team here for 2.5 months, and working hard with them to finalize the document and have a prototype implementation for that by the next meeting. We conculded to modify the document - remove grpc_data_read, since it's functionality overlaps with grpc_data_write - rename grpc_data_write to grpc_data_transfer, to make it more clear - to add 'const' everywhere we can put to comply modern C standard. If you have any comments on the changes, please send us e-mail. we will send the updated document ASAP. regards, -- HIDEMOTO NAKADA, Ph.D, AIST, Japan

6 12