Hi Eddy, Thanks for your reply.
-------------------------------------------------------------------
* 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.
Ok. The sentence has been back to the document and corrected as you commented.
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)
I see. "full interoperability" was changed to "binary level interoperability" and I added the statement, "Note that interoperability at the client source code level (100% compatibility if the client source code is Grid-RPC API compliant) is in our scope." Thanks, ----------------------------------------------------- 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