
All, We will have a session in Italy next month, on Tuesday morning. Please plan your trip so that you can join us. #Unfortunately, I can not make the trip, but Eddy will lead the session. I'm now in Lyon, visiting DIET team here for 2.5 months, and working hard with them to finalize the document and have a prototype implementation for that by the next meeting. We conculded to modify the document - remove grpc_data_read, since it's functionality overlaps with grpc_data_write - rename grpc_data_write to grpc_data_transfer, to make it more clear - to add 'const' everywhere we can put to comply modern C standard. If you have any comments on the changes, please send us e-mail. we will send the updated document ASAP. regards, -- HIDEMOTO NAKADA, Ph.D, AIST, Japan

Hello, here is the new version of the API proposal. Please feel free to send any remark about it on the mailing list. Best regards, G. Le Mahec.

I was surprised that this document no mention of SAGA... I understood there was work going on to integrate the two APIs together at some level... or at least to utilise the SAGA 'look and feel' in future GridRPC work? Thanks, Steven Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse
-----Original Message----- From: gridrpc-wg-bounces@ogf.org [mailto:gridrpc-wg-bounces@ogf.org] On Behalf Of Gaël Le Mahec Sent: 18 February 2009 16:10 To: Mailing List for GRIDRPC-WG Subject: [GRIDRPC-WG] New version of the document
Hello,
here is the new version of the API proposal. Please feel free to send any remark about it on the mailing list.
Best regards,
G. Le Mahec.

Dear Steven, What do you mean ? For me SAGA is on the top of many API. And SAGA was on the top of the GridRPC without data management. Now we add the data management in the GridRPC but it should be compliant to the overload of the SAGA API. When SAGA integrated GridRPC it was not at the same level but on the top of GridRPC. SAGA is THE API of the APIs. Then I don't underst and what do you mean by using the "look and feel" of SAGA ? Could you explain ? Nevertheless we hope this document open discussions with the SAGA WG as usual. Best regards, Eddy Le 19 févr. 09 à 18:36, Steven Newhouse a écrit :
I was surprised that this document no mention of SAGA... I understood there was work going on to integrate the two APIs together at some level... or at least to utilise the SAGA 'look and feel' in future GridRPC work?
Thanks,
Steven
Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse
-----Original Message----- From: gridrpc-wg-bounces@ogf.org [mailto:gridrpc-wg- bounces@ogf.org] On Behalf Of Gaël Le Mahec Sent: 18 February 2009 16:10 To: Mailing List for GRIDRPC-WG Subject: [GRIDRPC-WG] New version of the document
Hello,
here is the new version of the API proposal. Please feel free to send any remark about it on the mailing list.
Best regards,
G. Le Mahec.
-- 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 ] ------------------------------------------------------------------------------------------------

Hi Eddy, My understanding is that there has been discussions about the use of SAGA within the GridRPC group which I was surprised that there was not recognition of this in the document you circulated. The SAGA document has a 'look and feel' section (a set of conventions on how to operate APIs) in addition to specific sections on jobs, files, etc. The recent Service Discovery work expanded the set of SAGA APIs by using the same look and feel - but in a new area of functionality. Minimally I would have expected a new API from GridRPC to have followed the same conventions. Steven Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse From: Eddy Caron [mailto:Eddy.Caron@ens-lyon.fr] Sent: 19 February 2009 22:26 To: Steven Newhouse Cc: Gaël Le Mahec; Mailing List for GRIDRPC-WG Subject: Re: [GRIDRPC-WG] New version of the document Dear Steven, What do you mean ? For me SAGA is on the top of many API. And SAGA was on the top of the GridRPC without data management. Now we add the data management in the GridRPC but it should be compliant to the overload of the SAGA API. When SAGA integrated GridRPC it was not at the same level but on the top of GridRPC. SAGA is THE API of the APIs. Then I don't underst and what do you mean by using the "look and feel" of SAGA ? Could you explain ? Nevertheless we hope this document open discussions with the SAGA WG as usual. Best regards, Eddy Le 19 févr. 09 à 18:36, Steven Newhouse a écrit : I was surprised that this document no mention of SAGA... I understood there was work going on to integrate the two APIs together at some level... or at least to utilise the SAGA 'look and feel' in future GridRPC work? Thanks, Steven Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse -----Original Message----- From: gridrpc-wg-bounces@ogf.org [mailto:gridrpc-wg-bounces@ogf.org] On Behalf Of Gaël Le Mahec Sent: 18 February 2009 16:10 To: Mailing List for GRIDRPC-WG Subject: [GRIDRPC-WG] New version of the document Hello, here is the new version of the API proposal. Please feel free to send any remark about it on the mailing list. Best regards, G. Le Mahec. -- 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 ] ------------------------------------------------------------------------------------------------

Steve, We've never had such discussion at all. What makes you think like that? It might be possible to adopt the SAGA look and feel, but we are not interested in the part now. For us, the part is not essential. -- HIDEMOTO NAKADA, Ph.D, AIST, Japan On Fri, Feb 20, 2009 at 9:14 PM, Steven Newhouse <Steven.Newhouse@cern.ch> wrote:
Hi Eddy,
My understanding is that there has been discussions about the use of SAGA within the GridRPC group which I was surprised that there was not recognition of this in the document you circulated.
The SAGA document has a 'look and feel' section (a set of conventions on how to operate APIs) in addition to specific sections on jobs, files, etc. The recent Service Discovery work expanded the set of SAGA APIs by using the same look and feel – but in a new area of functionality.
Minimally I would have expected a new API from GridRPC to have followed the same conventions.
Steven
Dr Steven Newhouse
EGEE Technical Director
http://cern.ch/Steven.Newhouse
From: Eddy Caron [mailto:Eddy.Caron@ens-lyon.fr] Sent: 19 February 2009 22:26 To: Steven Newhouse Cc: Gaël Le Mahec; Mailing List for GRIDRPC-WG Subject: Re: [GRIDRPC-WG] New version of the document
Dear Steven,
What do you mean ?
For me SAGA is on the top of many API. And SAGA was on the top of the GridRPC without data management. Now we add the data management in the GridRPC but it should be compliant to the overload of the SAGA API.
When SAGA integrated GridRPC it was not at the same level but on the top of GridRPC. SAGA is THE API of the APIs. Then I don't underst and what do you mean by using the "look and feel" of SAGA ? Could you explain ?
Nevertheless we hope this document open discussions with the SAGA WG as usual.
Best regards,
Eddy
Le 19 févr. 09 à 18:36, Steven Newhouse a écrit :
I was surprised that this document no mention of SAGA... I understood there was work going on to integrate the two APIs together at some level... or at least to utilise the SAGA 'look and feel' in future GridRPC work?
Thanks,
Steven
Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse
-----Original Message-----
From: gridrpc-wg-bounces@ogf.org [mailto:gridrpc-wg-bounces@ogf.org] On
Behalf Of Gaël Le Mahec
Sent: 18 February 2009 16:10
To: Mailing List for GRIDRPC-WG
Subject: [GRIDRPC-WG] New version of the document
Hello,
here is the new version of the API proposal. Please feel free to
send any remark about it on the mailing list.
Best regards,
G. Le Mahec.
-- 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 ]
------------------------------------------------------------------------------------------------
-- gridrpc-wg mailing list gridrpc-wg@ogf.org http://www.ogf.org/mailman/listinfo/gridrpc-wg

Hi Hidemoto,
We've never had such discussion at all. What makes you think like that?
From conversations I've had at past OGFs! If the conversation has not taken place then it should. Please try and find some time with the SAGA folks in Catania.
It might be possible to adopt the SAGA look and feel, but we are not interested in the part now. For us, the part is not essential.
I would like a stronger reason to present to the standards council than the group feels 'that it its not a good idea'. Steven

Quoting [Steven Newhouse] (Feb 22 2009):
Hi Hidemoto,
We've never had such discussion at all.
Well, the SAGA group had this discussion - also with the DRMAA and GridCPR folx btw. And yes, we hoped that, at some point, people would simply adopt our L&F part, and add packages. But at the end its up to the individual groups if they want to do that, or not. Let a thousand flowers bloom, right? Oh well, three... ;-) Anyway, SAGA people will certainly try to add an update to their RPC package, which also incorporates the data management features. In previous OGF discussions, we already checked if that is expressable/implementable in SAGA (it is). As Hidemoto said, that would be on top of GridRPC. Yes, duplication of effort to some extent. Cheers, Andre.
What makes you think like that?
From conversations I've had at past OGFs! If the conversation has not taken place then it should. Please try and find some time with the SAGA folks in Catania.
It might be possible to adopt the SAGA look and feel, but we are not interested in the part now. For us, the part is not essential.
I would like a stronger reason to present to the standards council than the group feels 'that it its not a good idea'.
Steven -- Nothing is ever easy.

Andre and Steven, The following is my opinion. - SAGA l/f is cool. for the users who want to use several capabilities of Grid, SAGA l/f will ease their burden. - on the other hand, SAGA i/f is too rich for the users who just want to use one capability from the Grid, such as GridRPC. Without SAGA l/f, the API could be designed as simple as possible - once the specific API (such as GridRPC) is specified, to change the i/f to adopt SAGA l/f will be straight forward and relatively easy. l/f is not essential, for me. - therefore, in my opinion, the best way to specify an API on a specific area is that, -- specify the API in a way that is as simple as possible, -- then, adopt some l/f for the API if it is required. regards, - Hidemoto. On Sun, Feb 22, 2009 at 11:20 PM, Andre Merzky <andre@merzky.net> wrote:
Quoting [Steven Newhouse] (Feb 22 2009):
Hi Hidemoto,
We've never had such discussion at all.
Well, the SAGA group had this discussion - also with the DRMAA and GridCPR folx btw. And yes, we hoped that, at some point, people would simply adopt our L&F part, and add packages.
But at the end its up to the individual groups if they want to do that, or not. Let a thousand flowers bloom, right? Oh well, three... ;-)
Anyway, SAGA people will certainly try to add an update to their RPC package, which also incorporates the data management features. In previous OGF discussions, we already checked if that is expressable/implementable in SAGA (it is).
As Hidemoto said, that would be on top of GridRPC. Yes, duplication of effort to some extent.
Cheers, Andre.
What makes you think like that?
From conversations I've had at past OGFs! If the conversation has not taken place then it should. Please try and find some time with the SAGA folks in Catania.
It might be possible to adopt the SAGA look and feel, but we are not interested in the part now. For us, the part is not essential.
I would like a stronger reason to present to the standards council than the group feels 'that it its not a good idea'.
Steven -- Nothing is ever easy.

Good points. It would be cool though if you guys could help us to create a new RPC package at some point. In the SAGA group, it is a question of available manpower, and also of available expertise, if/wehn we can come up with and updated RPC package on our own... Cheers, Andre. Quoting [Hidemoto Nakada] (Feb 22 2009):
Andre and Steven,
The following is my opinion.
- SAGA l/f is cool. for the users who want to use several capabilities of Grid, SAGA l/f will ease their burden.
- on the other hand, SAGA i/f is too rich for the users who just want to use one capability from the Grid, such as GridRPC. Without SAGA l/f, the API could be designed as simple as possible
- once the specific API (such as GridRPC) is specified, to change the i/f to adopt SAGA l/f will be straight forward and relatively easy. l/f is not essential, for me.
- therefore, in my opinion, the best way to specify an API on a specific area is that, -- specify the API in a way that is as simple as possible, -- then, adopt some l/f for the API if it is required.
regards,
- Hidemoto.
On Sun, Feb 22, 2009 at 11:20 PM, Andre Merzky <andre@merzky.net> wrote:
Quoting [Steven Newhouse] (Feb 22 2009):
Hi Hidemoto,
We've never had such discussion at all.
Well, the SAGA group had this discussion - also with the DRMAA and GridCPR folx btw. And yes, we hoped that, at some point, people would simply adopt our L&F part, and add packages.
But at the end its up to the individual groups if they want to do that, or not. Let a thousand flowers bloom, right? Oh well, three... ;-)
Anyway, SAGA people will certainly try to add an update to their RPC package, which also incorporates the data management features. In previous OGF discussions, we already checked if that is expressable/implementable in SAGA (it is).
As Hidemoto said, that would be on top of GridRPC. Yes, duplication of effort to some extent.
Cheers, Andre.
What makes you think like that?
From conversations I've had at past OGFs! If the conversation has not taken place then it should. Please try and find some time with the SAGA folks in Catania.
It might be possible to adopt the SAGA look and feel, but we are not interested in the part now. For us, the part is not essential.
I would like a stronger reason to present to the standards council than the group feels 'that it its not a good idea'.
Steven -- Nothing is ever easy.
-- Nothing is ever easy.

Dear all, I think GridRPC with data management can be see by SAGA exactly with the same point of view as the GridRPC without data management. For a SAGA user, the GridRPC API is hidden. Then the 'look and feel' of SAGA is perfect for the SAGA API but I don't understand why the GridRPC API and SAGA API should follow the same look and feel. We started to discuss about the data management during GGF number 2 (in 2001 at Washington DC), and about the necessity to deal with this at the GridRPC WG level. After many discussions between Grid-RPC members, the SAGA WG (with Andre) helped us to decide to start to create this document (it was during the OGF'19 in 2007 at Chapel Hill). Indeed the SAGA WG requested to have this kind of feature to integrate a full version of GridRPC into SAGA. I have discussed with Gaël Le Mahec. He works with us since a few years and he could be the perfect manpower required for the SAGA group. See you soon in Catania. Best Regards, Eddy Le 23 févr. 09 à 00:06, Andre Merzky a écrit :
Good points.
It would be cool though if you guys could help us to create a new RPC package at some point. In the SAGA group, it is a question of available manpower, and also of available expertise, if/wehn we can come up with and updated RPC package on our own...
Cheers, Andre.
Quoting [Hidemoto Nakada] (Feb 22 2009):
Andre and Steven,
The following is my opinion.
- SAGA l/f is cool. for the users who want to use several capabilities of Grid, SAGA l/f will ease their burden.
- on the other hand, SAGA i/f is too rich for the users who just want to use one capability from the Grid, such as GridRPC. Without SAGA l/f, the API could be designed as simple as possible
- once the specific API (such as GridRPC) is specified, to change the i/f to adopt SAGA l/f will be straight forward and relatively easy. l/f is not essential, for me.
- therefore, in my opinion, the best way to specify an API on a specific area is that, -- specify the API in a way that is as simple as possible, -- then, adopt some l/f for the API if it is required.
regards,
- Hidemoto.
On Sun, Feb 22, 2009 at 11:20 PM, Andre Merzky <andre@merzky.net> wrote:
Quoting [Steven Newhouse] (Feb 22 2009):
Hi Hidemoto,
We've never had such discussion at all.
Well, the SAGA group had this discussion - also with the DRMAA and GridCPR folx btw. And yes, we hoped that, at some point, people would simply adopt our L&F part, and add packages.
But at the end its up to the individual groups if they want to do that, or not. Let a thousand flowers bloom, right? Oh well, three... ;-)
Anyway, SAGA people will certainly try to add an update to their RPC package, which also incorporates the data management features. In previous OGF discussions, we already checked if that is expressable/implementable in SAGA (it is).
As Hidemoto said, that would be on top of GridRPC. Yes, duplication of effort to some extent.
Cheers, Andre.
What makes you think like that?
From conversations I've had at past OGFs! If the conversation has not taken place then it should. Please try and find some time with the SAGA folks in Catania.
It might be possible to adopt the SAGA look and feel, but we are not interested in the part now. For us, the part is not essential.
I would like a stronger reason to present to the standards council than the group feels 'that it its not a good idea'.
Steven -- Nothing is ever easy.
-- Nothing is ever easy.
---------------------------------------------------------------------------------------------- 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 ] ------------------------------------------------------------------------------------------------

Quoting [Eddy Caron] (Mar 02 2009):
Dear all,
I think GridRPC with data management can be see by SAGA exactly with the same point of view as the GridRPC without data management. For a SAGA user, the GridRPC API is hidden. Then the 'look and feel' of SAGA is perfect for the SAGA API but I don't understand why the GridRPC API and SAGA API should follow the same look and feel.
We started to discuss about the data management during GGF number 2 (in 2001 at Washington DC), and about the necessity to deal with this at the GridRPC WG level. After many discussions between Grid-RPC members, the SAGA WG (with Andre) helped us to decide to start to create this document (it was during the OGF'19 in 2007 at Chapel Hill). Indeed the SAGA WG requested to have this kind of feature to integrate a full version of GridRPC into SAGA.
I have discussed with Gaël Le Mahec. He works with us since a few years and he could be the perfect manpower required for the SAGA group.
This would be great :-) Cheers, Andre.
See you soon in Catania.
Best Regards, Eddy
Le 23 févr. 09 à 00:06, Andre Merzky a écrit :
Good points.
It would be cool though if you guys could help us to create a new RPC package at some point. In the SAGA group, it is a question of available manpower, and also of available expertise, if/wehn we can come up with and updated RPC package on our own...
Cheers, Andre.
Quoting [Hidemoto Nakada] (Feb 22 2009):
Andre and Steven,
The following is my opinion.
- SAGA l/f is cool. for the users who want to use several capabilities of Grid, SAGA l/f will ease their burden.
- on the other hand, SAGA i/f is too rich for the users who just want to use one capability from the Grid, such as GridRPC. Without SAGA l/f, the API could be designed as simple as possible
- once the specific API (such as GridRPC) is specified, to change the i/f to adopt SAGA l/f will be straight forward and relatively easy. l/f is not essential, for me.
- therefore, in my opinion, the best way to specify an API on a specific area is that, -- specify the API in a way that is as simple as possible, -- then, adopt some l/f for the API if it is required.
regards,
- Hidemoto.
On Sun, Feb 22, 2009 at 11:20 PM, Andre Merzky <andre@merzky.net> wrote:
Quoting [Steven Newhouse] (Feb 22 2009):
Hi Hidemoto,
We've never had such discussion at all.
Well, the SAGA group had this discussion - also with the DRMAA and GridCPR folx btw. And yes, we hoped that, at some point, people would simply adopt our L&F part, and add packages.
But at the end its up to the individual groups if they want to do that, or not. Let a thousand flowers bloom, right? Oh well, three... ;-)
Anyway, SAGA people will certainly try to add an update to their RPC package, which also incorporates the data management features. In previous OGF discussions, we already checked if that is expressable/implementable in SAGA (it is).
As Hidemoto said, that would be on top of GridRPC. Yes, duplication of effort to some extent.
Cheers, Andre.
What makes you think like that?
From conversations I've had at past OGFs! If the conversation has not taken place then it should. Please try and find some time with the SAGA folks in Catania.
It might be possible to adopt the SAGA look and feel, but we are not interested in the part now. For us, the part is not essential.
I would like a stronger reason to present to the standards council than the group feels 'that it its not a good idea'.
Steven -- Nothing is ever easy.
-- Nothing is ever easy.
---------------------------------------------------------------------------------------------- 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 ] ------------------------------------------------------------------------------------------------
-- Nothing is ever easy.

HI, I have uploaded the same file to the OGF25 web site. cheers, -- HIDEMOTO NAKADA, Ph.D, AIST, Japan 2009/2/18 Gaël Le Mahec <lemahec@clermont.in2p3.fr>:
Hello,
here is the new version of the API proposal. Please feel free to send any remark about it on the mailing list.
Best regards,
G. Le Mahec.
-- gridrpc-wg mailing list gridrpc-wg@ogf.org http://www.ogf.org/mailman/listinfo/gridrpc-wg
participants (6)
-
Andre Merzky
-
Eddy Caron
-
Eddy Caron
-
Gaël Le Mahec
-
Hidemoto Nakada
-
Steven Newhouse