Dear all, ###### Summary of the session ##################### Hidemoto Nakada presented the session. The GridRPC API lity is now an OGF standard. Gaël Le Mahec presented the work performed on a proposition for GridRPC Data Management API from GRAAL's Team (Yves Caniou, Eddy Caron, Frederic Desprez and Gaël Le Mahec) Two discussions were conducted then: -1- concerning the Data Management API -2- concerning the proposition of extending the GridRPC API with array functions, in order to submit arrays of data ###### Points to discuss and improvements since the meeting ##### -1- Concerning the Data Management API There was some errors and some helpful suggestions on the slides, which have been accordingly corrected. A new version of slides can be found at http://graal.ens-lyon.fr/~ycaniou/GridRPC/OGF-21.pdf Note that similar corrections have also be made in the Data Management API proposition. Furthermore, the document has evoluted with some modifications described above. It is available at http://graal.ens-lyon.fr/~ycaniou/GridRPC/GRPC_Data-0.5.pdf Changelog is: **** Modifications . For coherence with naming convention, changed - 'grpc_DM_type_t' for 'grpc_data_type_t' - 'grpc_DM_mode_t' for 'grpc_data_mode_t' . Slides 18, 'grpc_info_type'->'grpc_info_t' . Added pointers in all functions for grpc_data_t . Slide 23, miss a ',' . Slides 28, 31, don't use NULL for grpc_data_mode_t but GRPC_VOLATILE as default (requested by all ) . Renammed 'DOUBLE' by 'GRPC_DOUBLE', 'ARRAY_OF_INT' by 'GRPC_ARRAY_OF_INT', etc. . Make all grpc_data_mode_t preceded by 'GRPC_', for example 'VOLATILE' is now 'GRPC_VOLATILE' **** Additions . Add type of diffusion, like broadcast, etc., used by software like omniStorage in grpc_data_write() **** Novelties . Use an URI for the save and load functions. A small change that leads to much more possibilities. . The grpc_data_free() functions was not well defined concerning the freeing of the data on the different available locations. We have splitted in grpc_data_unbind() and grpc_data_free() as commented in the document. . Added the GRPC_CONTAINER_OF_GRPC_DATA type for a grpc_data_t variable. . Added 2 functions grpc_data_container_add() and grpc_data_container_get() Should we include some additional functionalities? . Add a new function ? grpc_error_t grpc_data_transfer_wait(grpc_data_t* data, grpc); because some transfers can be synchronous or asynchronous... -> The user can know for sure that the data is in place. -2- Concerning the proposition of extending the GridRPC API with array functions. . The objectives of this proposition is to make possible to use array of data in one call. For example, a GridRPC call with 3 arguments could be made with a GridRPC with one array argument of 3 data. . Two points of view are discussed here: . Some of us want to provide a new additional API. . Some others find that it has some overlap with the OGF GridRPC API standard and that functionalities are/must be already included within the Data Management API. -> Both groups said that they would provide a document describing their arguments describing why a given solution is better, with an example. => Our document can be accessed through http://graal.ens-lyon.fr/~ycaniou/GridRPC/implementation_examples.pdf ------------------------------ Conclusion ---------------------------------- The OGF meeting was a great moment, with entertaining discussions. Very useful remarks have been made, that gave us a good motivation to keep on. Thank you for the stimulating discussion in Seattle. In order to make strong progress in the proposition, we suggest that people takes each point and comments it, explaining why he agrees or disagrees with a special item. The next OGF is not far now, I really apologize not to have given any news before. I hope to see all of you there. Best Regards. .Yves.