New version of the proposal of the API for GridRPC Data Management
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.
Yves and All, Thank you for your mail. We will have a F2F next week at Cambridge, MA, on Monday morning. I'm looking forward to see you all again there. The agenda will be the data handle issue. One issue caused stimulating discussion on the previous f2f meeting was 'should we have dedicated type for argument list'. I'm almost convinced to have the data_handle structure also works as argument list. Let us discuss on the document Yves send us. Thanks and see you soon! On Feb 6, 2008 10:59 AM, Yves Caniou <yves.caniou@ens-lyon.fr> wrote:
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. -- gridrpc-wg mailing list gridrpc-wg@ogf.org http://www.ogf.org/mailman/listinfo/gridrpc-wg
-- HIDEMOTO NAKADA, GTRC, AIST
Dear All, I have put the slides of the presentation at the URL: http://graal.ens-lyon.fr/~ycaniou/GridRPC/OGF-22.pdf They may change, but the main points are normally present ;) See you soon! .Yves. Le Tuesday 19 February 2008 10:35:07 Hidemoto Nakada, vous avez écrit :
Yves and All,
Thank you for your mail.
We will have a F2F next week at Cambridge, MA, on Monday morning. I'm looking forward to see you all again there.
The agenda will be the data handle issue. One issue caused stimulating discussion on the previous f2f meeting was 'should we have dedicated type for argument list'.
I'm almost convinced to have the data_handle structure also works as argument list.
Let us discuss on the document Yves send us.
Thanks and see you soon!
On Feb 6, 2008 10:59 AM, Yves Caniou <yves.caniou@ens-lyon.fr> wrote:
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. -- gridrpc-wg mailing list gridrpc-wg@ogf.org http://www.ogf.org/mailman/listinfo/gridrpc-wg
Dear All, I have updated the slides of the presentation at the URL: http://graal.ens-lyon.fr/~ycaniou/GridRPC/OGF-22.pdf Best Regards. .Yves. Le Tuesday 19 February 2008 10:35:07 Hidemoto Nakada, vous avez écrit :
Yves and All,
Thank you for your mail.
We will have a F2F next week at Cambridge, MA, on Monday morning. I'm looking forward to see you all again there.
The agenda will be the data handle issue. One issue caused stimulating discussion on the previous f2f meeting was 'should we have dedicated type for argument list'.
I'm almost convinced to have the data_handle structure also works as argument list.
Let us discuss on the document Yves send us.
Thanks and see you soon!
On Feb 6, 2008 10:59 AM, Yves Caniou <yves.caniou@ens-lyon.fr> wrote:
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. -- gridrpc-wg mailing list gridrpc-wg@ogf.org http://www.ogf.org/mailman/listinfo/gridrpc-wg
Dear All, I have updated the slides of the presentation, the implementation document (which is now version 0.6) as well as the document of the Data Management API. All are available at the URL: http://graal.ens-lyon.fr/~ycaniou/GridRPC/ Changelog is: .Modifications in the presentation OGF-22 and in the document: - Use a '*' for args as most as possible (to avoid copy of data in C syntax) - Set the name of the function 'grpc_data_container_add()' to grpc_data_container_set() .Additionnal modifications in the presentation and implementation example: - Changed mode of d1 and pool from NULL to GRPC_VOLATILE (sl 15) .Additionnal modifications in the presentation: - grpc_data_free() prototype was wrong Next step is the merge of the implementation example in the document, work on the error codes and the asynchronous mechanisms. Best Regards and thank you! .Yves. Le Tuesday 19 February 2008 10:35:07 Hidemoto Nakada, vous avez écrit :
Yves and All,
Thank you for your mail.
We will have a F2F next week at Cambridge, MA, on Monday morning. I'm looking forward to see you all again there.
The agenda will be the data handle issue. One issue caused stimulating discussion on the previous f2f meeting was 'should we have dedicated type for argument list'.
I'm almost convinced to have the data_handle structure also works as argument list.
Let us discuss on the document Yves send us.
Thanks and see you soon!
On Feb 6, 2008 10:59 AM, Yves Caniou <yves.caniou@ens-lyon.fr> wrote:
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. -- gridrpc-wg mailing list gridrpc-wg@ogf.org http://www.ogf.org/mailman/listinfo/gridrpc-wg
participants (2)
-
Hidemoto Nakada -
Yves Caniou