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

[Hidemoto Nakada]

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
>



-- 
   HIDEMOTO NAKADA, GTRC, AIST