All,
After the last GridRPC meeting in Seoul, we promised to send a new
proposal for data management in GridRPC and an answer to Hidemoto's
comments. However, in our discussions we still face a problem on the
definition of function handles.
There two ways to initialize a function handle.
- first, we can do it with grpc_function_handle_init. In this case, the
server is explicitly given by the client. As data location is known
(client, server or data repository), there no problem to bind the data
to the server. All data management can be done by the client:
placement, transfers or removal. The location will be given in the data
management functions.
- second, the function handle could be initialized by
grpc_function_handle_default. In that case, the GridRPC API document
says: "This default could be a pre-determined server or it could be a
server that is dynamically chosen by the resource discovery mechanisms
of the underlying GridRPC implementation". Does that mean, the function
handle will contain a server reference in it after
grpc_function_handle_default call ? Or does that mean, the function
handle will reference a default discovery (or GridRPC server) while the
computational server will be chosen during grpc_call ?
If the function handle contains a reference to a server, then the data
management can be done in the same way as for
grpc_function_handle_init. If the function handle does not reference
the computational server, there no way to know where to place data
before issuing grpc_call. This is the way function handles are
implemented in Diet and Netsolve (2.0, any changes ?)
GridRPC interfaces.
However, we should provide a way to dynamically choose a server...
Any comments ?
L. Philippe & B. DelFabbro
--
Laurent PHILIPPE http://lifc.univ-fcomte.fr/~philippe
philippe(a)lifc.univ-fcomte.fr Laboratoire d'Informatique (LIFC)
tel: (33) 03 81 66 66 54 route de Gray
fax: (33) 03 81 66 64 50 25030 Besancon Cedex - FRANCE
Dear GridRPC Colleagues,
The SAGA design team (Simple API for Grid Applications) has produced a
strawman API document that will be discussed at GGF-14. This strawman
document is part of the "discovery process" that SAGA must go through
prior to becoming a working group and producing a GGF Recommendation
document.
Hence, we want to get as many comments as possible on this document.
It is available in txt and pdf at:
http://wiki.cct.lsu.edu/saga/space/start/strawman-api.txthttp://wiki.cct.lsu.edu/saga/space/start/strawman-api.pdf
Comments can be made by posting to the SAGA mailing list (saga-rg(a)ggf.org)
(if you are subscribed to it) or by sending email directly to
Andre Merzky <andre(a)merzky.net> and Shantenu Jha <s.jha(a)ucl.ac.uk>.
This document really only covers eight concepts: Name Spaces, Files,
Logical Files, Jobs, Streams, Attributes, Error Handling, and Tasks.
Hence, it is relatively easy to understand the overall design approach
and whether it fits your design needs. Because this document
specifies the API down to every argument for every call, however, it
is 87 pages in length, but don't be scared off! It really has a very
simple structure.
Please forward this request to anyone who might be interested.
Thanks!
--Craig
