Hi, Eddy,

Could you give a dead-line to send comments ? I will discuss with the DIET Team about this document.

How about April 23? Thanks,

Sure ! Thanks for this input.

Could you give a dead-line to send comments ? I will discuss with the DIET Team about this document.

Regards, Eddy

Le 15 avr. 08 $B_
(B11:22, Yusuke Tanimura a $BqD(Brit :

...

Dear all,

I am posting this email on behalf of Hidemoto.

Our current chater is out of date and we are being asked to review and update the charter by GFSG.

An attached file is a draft recharter document which revised to reflect some of our discussion in OGF22. I think one of the biggest changes would be to specify the time schedule for "A GridRPC Model and API for Middleware Developers" document. DIET team, could you check if this schedule is ok for you?

First Draft: 2008-06 Public Comment: 2008-08 (I added) Publication: 2008-12 (I added)

If there is any other description to be updted (e.g. Group Focus and Scope), please raise a discussion.

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 <Charter for GRIDRPC-WG.html>-- 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 ] ------------------------------------------------------------------------------------------------

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

Hi Steven and all,

The download stats are good in demonstrating potential uptake of this work... anything more recent than 6 years ago? Commercial use... not essential... just asking!

I updated the download stats for Ninf-G. If anyone can provide the latest stats for NetSolve, I will reflect it to the document. ----------------------------------------------------- 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

Dear Yusuke, Please find a new version (I add a date range about the download of DIET). And I fixed few bugs due to coding systems (I see \200\232 characters). And with Yves we have few comments 1. "NetSolve is the most widely deployed and used." but the amount of download for Ninf is more important ? Ok not on the same years but... maybe the correct sentence is "NetSolve is widely deployed and used" 2. About download of NetSolve again, " For the last three years, the NetSolve website has logged the following number of downloads per year: The number of downloads is 627 in 2000, 831 in 2001 and 1106 in 2002.", this sentence is not up-to-date, have you the log for 2005, 2006, 2007 (the current last three years) ? 3. "A recent download log file (containing only 676 downloads)" then I'm not sure what means "recent" due to previous log ? 2003 or 2008 ? 4. About download of Ninf. "The Ninf-G group reports the cumulative number of downloads since the first release of Ninf-G: 1325 in Ninf- G2, 1132 in Ninf-G4, and 21 in Ninf-G5 at the end of April in 2008.". But in cumulative way the number of download must be increase all the time, isn't it ? You should remove the word "cumulative". Or update your cumulative download respectively to 1325, 2457 and 2478 (but for homogeneous results with NetSolve and DIET I think it's better to avoid the cumulative way). Regards, Eddy Le 14 mai 08 à 06:12, Yusuke Tanimura a écrit :

Dear all,

I attach the latest recharter document to this e-mail.

In this version, the summary was modified according to Steven's comment:

...

I feel your summary could be a bit shorter... say less about what you have done and more about what you are going to do! Also... are all of the points in the scope going to be covered in a single document? If they are please make that clearer... if the is going to be work that you are interested in doing after the next document and partition up the goals a bit more. Keep the things that you are not going to be doing... that's good!

If you have further comment or objection to any description in the document, please speak up. If no comment or objection within a week, the document will be sent to AD.

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 <Charter for GRIDRPC-WG-0511.html>-- 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 ] ------------------------------------------------------------------------------------------------

Le 17 mai 08 à 19:18, Yusuke Tanimura a écrit :

Hi Eddy,

...

Please find a new version (I add a date range about the download of DIET). And I fixed few bugs due to coding systems (I see \200\232 characters).

I am sorry. Where can I find it? Is this page updated? http://graal.ens-lyon.fr/~ecaron/Charter%20for%20GRIDRPC-WG.html

Oups. Sorry I forgot to attach the file. You can find here : http://graal.ens-lyon.fr/~ecaron/GridRPC/Charter%20for%20GRIDRPC-WG-0516.htm... or in attachement in this mail. ---------------------------------------------------------------------------------------------- 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 ] ------------------------------------------------------------------------------------------------

Hi,

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 - Blue color for what I have added

Thank you, Eddy and Yves. I reflected blue color part, and some of the following into the recharter document because it seems there is no objection to them. I will send another email for other issues. ----------------------------------------------------------------------- * Definition of a specific data structure to be used for GridRPC arguments in middleware, e.g., a stack, a vector, etc. Comment from DIET team: During the two last OGF we discussed about a new structure for data management and we seemed agree to validate the current document with few update given by the Japanese team. But the new structure works without the vector. In this Charter we could remove the "e.g., a stack, a vector, etc." until we finish the current discussion. Action: Removed "e.g., a stack, a vector, etc." ----------------------------------------------------------------------- ----------------------------------------------------------------------- * Definition of a "grpc_arg" data type, if necessary. Comment from DIET team: with Andree and Hidemoto, at the last OGF it was clear that it's necessary. We should remove the "if necessary", to be used in conjunction with the argument data structure. Action: Removed "if necessary." ----------------------------------------------------------------------- ----------------------------------------------------------------------- Title: A GridRPC Model and API for Middleware Developers Comment from DIET team: We have a little problem with this title. If we talk about the same document, means the API with more functionalities as data management. It's an extended version of the GridRPC Model and API or expert version or version 2.0 as you wish. But why GridRPC users can not use this API ? It's not clear for us. If we talk about the same document why you don't keep the title "Data Management API within the GridRPC" ? Action: Changed the title to "Data Management API within the GridRPC." ----------------------------------------------------------------------- ----------------------------------------------------- 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

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