Le 1 mai 08 à 15:28, Yusuke Tanimura a écrit :
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.
OK, I see. Then maybe it's more clear like this : * Definition of possible introspection capabilities for call arguments and attributes of remote functions (e.g. data types, counts, etc.) OK, it's a detail, it's not realy important. You can ignore this comment, as you wish.
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.
No you are right, this kind of function could be useful.
-------------------------------------------------------------------
* 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.
yes. If think it's a good way to keep the interoperability at the source code level.
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?
Yes it's more clear. But as you explain before you can define what do you mean by full interoperability (you mean at the binary level). I think it's important to remember that we plan to have an interoperability at the client source code level (100% compatibility if the client source code is Grid-RPC API compliant) Best regards, Eddy
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
-- gridrpc-wg mailing list gridrpc-wg@ogf.org http://www.ogf.org/mailman/listinfo/gridrpc-wg
---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------