[GRIDRPC-WG] New version of the API

[Yves Caniou]

Dear All,

First, I apologize for the delay.

I have put the new version 0.7 of the document at the URL:
http://graal.ens-lyon.fr/~ycaniou/GridRPC/GRPC_Data-0.7.pdf
(all docs are available at http://graal.ens-lyon.fr/~ycaniou/GridRPC/).

We plan to use the document itself as a presentation support. 

-----------------
Changelog (main features):

* Correction typos
* Moved types only used in given function in the section describing types
* Instead of only an input URI and output URI, the
grpc\_data\_storage\_info\_t type has now a NULL-terminated list of
input URI and a NULL-terminated list of output URI.

* grpc_data_mode_t was a bit confusing because it mixed a modification
in the behavior of the standard GridRPC mechanism (return the data at
the end of the computation) and the management mode of a GridRPC
data. Then,
 - GRPC_*_RETURN values have been removed from grpc_data_mode_t
 - grpc_data_mode_t has been extended with the values GRPC\_UNIQUE\_VOLATILE
   and GRPC_UNIQUE_STICKY, which do not tolerate migration/replication
   of the data, for security reasons for example.
 - grpc_data_init() contains an argument which describes the behavior
   of the standardized GridRPC API: for a given handle used as an OUT
   arg in a solve() function, one can choose to get or not a copy of the
   results.

Precision concerning the protocole LOCAL_MEMORY: the path is not
necessarily a pointer (which was given as example) but can also be a
kind of ID.

Modification of grpc_data_init():
- lists of locations in URL_input and URL_output args are now given.
- grpc_data_init() contains an argument which describes the behavior
  of the standardized GridRPC API: for a given handle used as an OUT
  arg in a solve() function, one can choose to get or not a copy of the
  results. (Already mentioned above)

Modification of the prototype of grpc_data_write():
- The list of servers is replaced by a list of URI, because the
protocol and the path can be different for each destination.
- A list of management modes can be specified, for example to flag a
data STICKY on some resources while still benefiting of aggressive
copy mechanisms if some are available in the data middleware.
- This function is asynchronous.

Modification of the description of grpc_data_read(), which is now
asynchronous.

Added the grpc_data_wait() function

Added 3 values-tags for the use of grpc_data_getinfo():
- GRPC_RESOLUTION_MODE to know if a copy is returned after computation.
- GRPC_STATUS in order to know if a grpc data is
              GRPC_IN_PLACE or GRPC_TRANSFERING.
- GRPC_COHERENT in order to know if the data is managed by a Data
  Management middleware that ensures coherency (and then, if this replica
  may or is up-to-date) -- should be dependent on locations.

Added a new example for prefetch, and corrected the others.
---------------

See you soon!

.Yves.

-- 
Yves Caniou
Associate Professor at Université Lyon 1
Member of the team project INRIA GRAAL,
LIP / ENS-Lyon
46 Allée d'Italie 
69364 LYON Cedex 07 
tel: +33 4 37 28 76 48 
http://graal.ens-lyon.fr/~ycaniou/