[GRIDRPC-WG] New version of the document

Andre Merzky andre at merzky.net
Sun Mar 1 18:25:50 CST 2009


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



-- 
Nothing is ever easy.


More information about the gridrpc-wg mailing list