gridrpc-wg

Download

gridrpc-wg@lists.ogf.org

June 2008

3 participants
2 discussions

Group rechartering
by Yusuke Tanimura 13 Jun '08

13 Jun '08

Dear all, We discussed about the recharter at the session in OGF 23. Thanks for all participants! Attachment is a revised version according to our discussion. * Download statistics of NetSolve/GridSolve is updated. * Document type of "Data Management API within the GridRPC" is changed from Recommendation to Informational. * A new planned recommendation document, "A GridRPC Model and API v2," is added to our deliverables. It is really time to finalize and send the document to the area director. Please give us any further comments within a week if you have. Best regards, ----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura(a)aist.go.jp> Information Technology Research Institute, AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601

2 2

New version of the API
by Yves Caniou 03 Jun '08

03 Jun '08

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/

2 1