I read the draft and I have several remarks about it. Lot of them are about small details or about matter of taste. But 
two of them which are about data descriptions and about default servers are more serious.

This document is about the GridRPC API and does not discuss the interest of the GridRPC. But when I read the title "a 
GridRPC model and API for End-User application", I am waiting for a discussion about RPC paradigm. Maybe "GridRPC API 
for End-User application" is more accurate.

RPC means remote PROCEDURE call. But GRPC does remote grpc_FUNCTION_handle calls. If I am not wrong, procedures allow 
side effects and functions do not. A procedure can return different values for different calls, a function must always 
return the same value for the same sequence of arguments. I think, we can add a small line explaining that the grpc 
functions are in reality procedures like C functions.

Page 2, the basic GridRPC Model: It is written, "the service handle is a function handle which represents a mapping from
 a simple, flat function name string to an instance of that function on a particular server". I have two remarks about 
it. Firstly what is a server ? Is it a computer, a program or a process ?  Secondly, if I am not mistaking, the term "
service handle" is used only once in the document. So, this term is probably not necessary.


I am not an MPI expert and my English is not good, but I found the term "session ID" disturbing. For me, a session 
starts with grpc_initialize and stop with grpc_finalize. I think that the term "call ID" is easer to understand than the
 term "session ID".


Page 3 Service discovery: There is a small detail here. For me, discovery mechanisms and lookup mechanisms are two 
opposites. What do you think about the difference between discovery and lookup describe in in http://citeseer.ist.psu.
edu/mcgrath00discovery.html

Page 3 General Workflow: The first word of the paragraph is "Defininf". I think it should be "Defining".


Page 4. Describes grpc_initialize and grpc_finalize. Is it possible for a process to make several calls to 
grpc_initialize ? What should append if two threads of the same process use simultaneously grpc_initialize or 
grpc_finalize ?

Page 4. The grpc_finalize description tells that "this function releases any resources being used by GridRPC". Does it 
also include the canceling of all the not finished asynchronous calls ? 

Page 4. the grpc_function_handle_default and grpc_function_handle_init name are not self explicit. Perhaps, 
grpc_function_handle and grpc_function_handle_on_host would be better.

Page 4 grpc_function_handle_default. The definition of GRPC_SERVER_NOT_FOUND is "GRPC client cannot find any server". 
What does it means ?
- there is no server on the platform
- every server is overloaded
- there is no default server left
- the default server does not exist
- there is no server implementing the function

Page 4 grpc_function_handle_default. "... is chosen by the resource discovery mechanisms...". The resource discovery 
mechanisms was not defined. It is for the service discovery of page 3 or a computer hosts discovery ?

Page 4 grpc_function_handle_default. "This creates a new function handle using a default server...". This means that the
 returned handle is bound with a specific computer host.  The DIET platform uses another mechanism. The DIET 
function_handle function returns an handle which allows the client to make a remote procedure call on a specific 
function. When a client makes a call, the platform find the best suited server depending of the current load of the 
servers. This means that if a client send a burst of 4 calls with the same handle, then there is a good chance that 4 
different hosts will be used. However, the DIET mechanism seams to be not compatible with the GridRPC one where the 
default server is a specific computer.

Page 4 grpc_function_handle_default and grpc_function_handle_init: Maybe we should add a GRPC_RPC_REFUSED if the client 
have no right to get...