[GRIDRPC-WG] Recharter?

[Yusuke Tanimura]

Hi Eddy and Yves,

> 	We discussed with Yves Caniou about this document and I merged all  
> our comments. I use the following syntaxe
> 
> - Green color for comments or questions

I will reply to two of your comments below.

-------------------------------------------------------------------
> * Definition of possible introspection capabilities for call
> arguments and attributes.

Your comment: 
Each item is clear. This one seems more vague, no ? An example
should be useful.
-------------------------------------------------------------------
I heard this is to define client APIs and/or a model for retrieving
arguments information (e.g. data types, counts) of remote functions.
For example, if we implement higher-level API such as task-farming
over GridRPC, we may need this kind of function.

Do you think if the function is necessary for your proposed "Data
Management API?"  If not, because this recharter should focus on
"Data Management API," we should remove the sentence from the
recharter document.


-------------------------------------------------------------------
> * Interoperability between implementations -- achieving
> interoperability between implementations requires defining, in
> essence, a wire protocol. This is actually orthogonal to the
> problem of defining the user-level model and API and, hence, can
> be done later as part of a separate effort.

Your comment:
Why ? It could be more relevant to have this interoperability as
a proof of concept. And implementation offers new approach or at
least allows to finalize the API. I understand it could be
dangerous to promise something like that in this charter but put
this in the non-objectives part is strange. The nice work
provided by Yusuke Tanimura with the client code for testing
interoperability was very useful, we can continue this work to
provide a Grid-RPC compliant benchmark suite (not for
performances, but for a behavior required). Moreover in section
Goals/delivrables you wrote "By doing so, this document will
also facilitate the development of multiple implementations"
and it's right then how this is in goals and in non-objectives
part ? Maybe I don't understand something
-------------------------------------------------------------------
The original sentence discusses about wire protocol interoperability
between implementations.  For example, DIET client binary should
communicate with Ninf-G server binary, and vice-versa.  However,
we only defines client APIs and does API conformance test now.  The
previous test we did was performed in each implementation, though
source code of the client program was the same.

So, I propose modifying the sentence as follows,

* Wire protocol interoperability between implementations -- achieving
full interoperability between implementations requires defining, in
essence, a wire protocol.  This is actually orthogonal to the problem
of defining the user-level model and API and, hence, can be done later
as part of a separate effort.

What do you think?


Best regards,

-----------------------------------------------------
Yusuke Tanimura <yusuke.tanimura at 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