[GRIDRPC-WG] Recharter?

[Eddy Caron]

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 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
>
> --
>  gridrpc-wg mailing list
>  gridrpc-wg at 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 at ens-lyon.fr
[ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ]
------------------------------------------------------------------------------------------------