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/