Thanks Eddy, To keep track changes in documents, OGF requires documents in Word. I'll convert it into Word format, hopefully, within next two weeks. And, of course, we are waiting for your talk. have a good vacation! -- HIDEMOTO NAKADA, GTRC, AIST 2007/7/21, Eddy Caron <Eddy.Caron@ens-lyon.fr>:

Dear Hidemoto Nakada,

Yes it's a latex version. We can convert in .doc if needed. With Yves Caniou we have corrected some part of the first version to take into account internal remarks from the GRAAL Team.

New version available here (version 0.2):

http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data.pdf

Source files are available here :

http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data_OGF21.tar.gz

With Yves Caniou and Frederic Desprez we attend to OGF21 and we can give a talk around this document. Could you keep a slot for this working group.

Regards, Eddy PS: Just for information, I will be off line during the next two week.

Le 17 juil. 07 à 17:34, Hidemoto Nakada a écrit :

...

Eddy, could you send us the source (latex, i guess) file?

thanks. -- HIDEMOTO NAKADA, GTRC, AIST

2007/6/26, Eddy Caron <Eddy.Caron@ens-lyon.fr>:

...

Dear GridRPC member,

From a preliminary version written by E Caron, F Desprez, JM Nicod and L Philippe we designed a new version of the proposal for a management of the API data in GridRPC. This new approach tries to take into account remarks from Craig Lee and Hidemoto Nakada.

With the Graal team, I have organized the differents meeting and Yves Caniou resumed our ideas in this paper (thanks to him).

Many things have changed in this version and it's not a final version. But we need your remarks and comments to improve this document and finish it.

Best regards, Eddy Caron and Yves Caniou

--------------------------------------------------------------------- -------------------------

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.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ]

--------------------------------------------------------------------- ---------------------------

-- 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.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------ ------------------------

All, I'm so sorry for taking so much time to just merging document... I'm quite a novice on the 'MS Word'. here is the first version of the merged one. I found several things to be addressed in the document. - function naming convention the end user api uses grpc_STRUCTURE-NAME_METHOD-NAME style. I think, for users convenience, should be kept in the middleware document. - constants the constant values, such as 'PERSISTENT' should be defined as c macro, and have 'GRPC' as prefix, to avoid conflicts with other modules. - document structure. I've just insert the data handle document as the chapter 3. while the array arguements are discussed in other chapters. we have to reconsider it. - reference I'm so novice that i do not know how to manage them. give me more time. anyway, please take a look, and give us comments. i'd like to revise this at least once before the F2F meeting in Seattle. regards, -- HIDEMOTO NAKADA, GTRC, AIST 2007/7/21, Hidemoto Nakada <hide-nakada@aist.go.jp>:

Thanks Eddy,

To keep track changes in documents, OGF requires documents in Word. I'll convert it into Word format, hopefully, within next two weeks.

And, of course, we are waiting for your talk.

have a good vacation! -- HIDEMOTO NAKADA, GTRC, AIST

2007/7/21, Eddy Caron <Eddy.Caron@ens-lyon.fr>:

...

Dear Hidemoto Nakada,

Yes it's a latex version. We can convert in .doc if needed. With Yves Caniou we have corrected some part of the first version to take into account internal remarks from the GRAAL Team.

New version available here (version 0.2):

http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data.pdf

Source files are available here :

http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data_OGF21.tar.gz

With Yves Caniou and Frederic Desprez we attend to OGF21 and we can give a talk around this document. Could you keep a slot for this working group.

Regards, Eddy PS: Just for information, I will be off line during the next two week.

Le 17 juil. 07 à 17:34, Hidemoto Nakada a écrit :

...

Eddy, could you send us the source (latex, i guess) file?

thanks. -- HIDEMOTO NAKADA, GTRC, AIST

2007/6/26, Eddy Caron <Eddy.Caron@ens-lyon.fr>:

...

Dear GridRPC member,

From a preliminary version written by E Caron, F Desprez, JM Nicod and L Philippe we designed a new version of the proposal for a management of the API data in GridRPC. This new approach tries to take into account remarks from Craig Lee and Hidemoto Nakada.

With the Graal team, I have organized the differents meeting and Yves Caniou resumed our ideas in this paper (thanks to him).

Many things have changed in this version and it's not a final version. But we need your remarks and comments to improve this document and finish it.

Best regards, Eddy Caron and Yves Caniou

--------------------------------------------------------------------- -------------------------

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.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ]

--------------------------------------------------------------------- ---------------------------

-- 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.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------ ------------------------

Dear Hidemoto and all, Please find a new version of the document and following comments. This new version take into account the helpful remarks of Hidemoto Nakada. New version available here (version 0.3): http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data.pdf Source files are available here : http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data_OGF21.tar.gz and a doc version (automatically generated with latex2rtf) (few bugs, I work to fix them) http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data.doc

I found several things to be addressed in the document.

- function naming convention the end user api uses grpc_STRUCTURE-NAME_METHOD-NAME style. I think, for users convenience, should be kept in the middleware document.

In fact the naming convention was not applied everywhere to the previous API (grpc_cancel,grpc_get_error, grpc_probe_or, etc.) that explain why we have do this mistake. But I think it's a very good idea. Then now all function are designed as grpc_data_METHOD-NAME

- constants the constant values, such as 'PERSISTENT' should be defined as c macro, and have 'GRPC' as prefix, to avoid conflicts with other modules.

done

- document structure. I've just insert the data handle document as the chapter 3. while the array arguements are discussed in other chapters. we have to reconsider it.

Yes. I have the same difficulty. I have applied your remarks on the document before the merge. The current proposition can manage different kinds of data type: array and more. Thus the previous function designed only for array seems too restrictif and too static, isn't it ? I don't know how to keep both approaches. We have work to design a complete API for data management with the following guidelines : - A small number of functions - A maximum of functionalities (every data management should be take into account) - No link with a middleware - As easy as possible

- reference I'm so novice that i do not know how to manage them. give me more time.

It's fine if we continue to work on latex file. And I can convert in MSword version at each time that is required.

anyway, please take a look, and give us comments.

i'd like to revise this at least once before the F2F meeting in Seattle.

Yes it's a great idea. If you have other remarks or If you think that we must keep the array function, let me know why and how. We could discuss about other points : The title of your document is "A GridRPC Model and API for Advanced and Middleware Applications" but we focus only on data management at this time. What do you suggest ? We discuss about data mangement to find the best way for the GridRPC and we add the workflow management in the next version ? I think we could give separate but complementary document. One for data management, another one for workflow management and so on. About the remark from Yusuke Tanimura about the new error code, Yves should give a full answer. He thinks it's not needed to modifiy the current API ( grpc_call() and grpc_call_async()) and I'm agree with him. But he will give more argmuments. We will discuss about that too. Regards, Eddy

regards, -- HIDEMOTO NAKADA, GTRC, AIST

2007/7/21, Hidemoto Nakada <hide-nakada@aist.go.jp>:

...

Thanks Eddy,

To keep track changes in documents, OGF requires documents in Word. I'll convert it into Word format, hopefully, within next two weeks.

And, of course, we are waiting for your talk.

have a good vacation! -- HIDEMOTO NAKADA, GTRC, AIST

2007/7/21, Eddy Caron <Eddy.Caron@ens-lyon.fr>:

...

Dear Hidemoto Nakada,

Yes it's a latex version. We can convert in .doc if needed. With Yves Caniou we have corrected some part of the first version to take into account internal remarks from the GRAAL Team.

New version available here (version 0.2):

http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data.pdf

Source files are available here :

http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data_OGF21.tar.gz

With Yves Caniou and Frederic Desprez we attend to OGF21 and we can give a talk around this document. Could you keep a slot for this working group.

Regards, Eddy PS: Just for information, I will be off line during the next two week.

Le 17 juil. 07 à 17:34, Hidemoto Nakada a écrit :

...

Eddy, could you send us the source (latex, i guess) file?

thanks. -- HIDEMOTO NAKADA, GTRC, AIST

2007/6/26, Eddy Caron <Eddy.Caron@ens-lyon.fr>:

...

Dear GridRPC member,

From a preliminary version written by E Caron, F Desprez, JM Nicod and L Philippe we designed a new version of the proposal for a management of the API data in GridRPC. This new approach tries to take into account remarks from Craig Lee and Hidemoto Nakada.

With the Graal team, I have organized the differents meeting and Yves Caniou resumed our ideas in this paper (thanks to him).

Many things have changed in this version and it's not a final version. But we need your remarks and comments to improve this document and finish it.

Best regards, Eddy Caron and Yves Caniou

------------------------------------------------------------------ --- -------------------------

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.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ]

------------------------------------------------------------------ --- ---------------------------

-- 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.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/ ~ecaron ] -------------------------------------------------------------------- ---- ------------------------

<Middleware_070828.doc> -- 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.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------ ------------------------

Dear Yusuke and all, Sorry to be that late anwering your mail. Le Tuesday 11 September 2007 11:41:10 Yusuke Tanimura, vous avez écrit :

Dear Eddy and all,

...

Yes it's a latex version. We can convert in .doc if needed. With Yves Caniou we have corrected some part of the first version to take into account internal remarks from the GRAAL Team.

New version available here (version 0.2):

http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data.pdf

Source files are available here :

http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data_OGF21.tar.gz

The spec introduces several new error codes. If we add GRPC_INVALID_TYPE and GRPC_INVALID_MODE to the spec, both could be returned in grpc_call() and grpc_call_async(), too, when the argument data does not match to what the server program expects.

We had a lot of discussions about returning error codes, and which ones to return depending on the case, within a grpc_call(). You are right saying that some kind of errors concerning Data Management can extend the GridRPC API and GridRPC interoperability document. For example, data transfer errors occuring on the server side could also be returned to the client for debugging purposes. For the moment, it can be interesting to add a GRPC_DATA_ERROR, without going deeper in the definition. We suggest to keep the GridRPC Data Management apart from the definition of error codes for the moment, which we can discuss later on because of the many cases to consider. Of course, all ideas, remarks and commentaries are always welcome.

I feel because data transfer becomes more complicated, a function to verify data types and etc. between senders and receivers would be helpful for users.

What can be done is to integrate into the GridRPC API a function to load all the services on a given server, with their parameter types? Of course, some kind of type checking can also be optionally performed when issuing the grpc_call(). And corresponding errors can be returned. But as said previously, maybe we should split error definitions from GridRPC Data Management API for the moment. Best Regards. .Yves.