[GRIDRPC-WG] New version of the proposal of the API for GridRPC Data Management
Yves Caniou
yves.caniou at ens-lyon.fr
Fri Feb 22 13:58:36 CST 2008
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 at 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 at ogf.org
> > http://www.ogf.org/mailman/listinfo/gridrpc-wg
More information about the gridrpc-wg
mailing list