GridRPC Telecon, Dec 5.
Attendence:  Craig Lee, Henri Casanova, Yoshio Tanaka, Hidemoto Nakada (briefly on IP phone)

Agenda:

1) Augment how "stack" arguments are handled.  We could retain the push/pop calls
but add the grpc_arg_stack_create_from_va_list() call and the grpc_arg_stack_copy() call.

2) Change the "stack" argument to a random-access "vector" argument type.  This will take
more work than just adding a couple of calls.

3) Adding a "grpc_arg" type.  As Henri says, this will require some thinking.

4) Satoshi M.'s comment on opacity vs. transparency is perhaps the most far-reaching
and difficult.  A good API should give the user a clean, consistent model but (if I understand
correctly) the user should also be able to "inspect" and "manage" the internal state of the
GridRPC model and its elements.  As a case in point, "stack" arguments should be manipulable.
In general, the more that a user can "mess around with", the more dangerous the API
becomes.  We need to carefully weigh what is absolutely necessary with its potential
for incorrect use.

-----

Several people (Henri and Hidemoto) suggested producing two different documents;
a simple, end-user doc and a complete, middleware doc.

Current issues with "stack" data type and handling of stack arguments should be
in middleware doc.  Discussion/resolution of "grpc_arg" type could be folded into
discussion/resolution of data_handles and workflow.  (grpc_arg and data_handles
might be the same or similar things; discriminated union?)

Get end-user doc out the door and then re-charter to produce the middleware doc.