[GRIDRPC-WG] New version of the proposal of the API for GridRPC Data Management

[Yves Caniou]

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 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