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

[Yves Caniou]

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.