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@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