[gridrpc-wg] questions about function handles

Laurent Philippe philippe at lifc.univ-fcomte.fr
Thu Jun 23 06:29:08 CDT 2005


Hidemoto,

Hidemoto Nakada wrote:
> Laurent
> 
> Could you (and/or some other people from your team) join the WG at the GGF 14 and 
> give us a presentation on the topic ?
Sorry, nobody from the team will join this GGF Session. We must follow 
our discussion by mail until next GGF 15.

>>I think the two solutions are not at the same level, but they both need
>>functions to access them. I think we should first complete the GridRPC
>>interface with data handles and data management functions. without
>>assuming anything on the way they are implemeneted. By just defining
>>functions, we do not assume anything on the underlying support. These
>>functions may be used to access/interface some 'magical' global data
>>management as well as a background support. This will depend on the
>>platform. By defining data management functions in GridRPC, we will
>>provide an homogenous and complete API to clients.
> 
> 
> To define an interface, we donot have to assume specific underlying
> mechanisms, but we have to assume underlying functionality.
> For example, if we can assume that the underlying system has automatic 
> data-caching and expiration mechanism, we donot have to have an
> API to control such things.
Yes we need it at least to optimize data transfers: just the client 
knows if the data must be leaved in the platform. We may assume an
underlying system with automatic data-caching and expiration mechanism, 
but with no data management support all the data (at least out data) 
will be sent back to the client after a computation request. In case of 
a request sequence the transfer may be useless, see the KMC example.
For that reason, it could be better to provide the data management 
interface to the client. However, you are right when you say :

> So, I belive, we have to agree on the 'richness' of the underlying
> system, to define an API.

For me, we can assume that the underlying system support at least data 
identification and data transfers (based on already existing mechanisms, 
we do not have to rewrite it). Then we may have different 'richness' 
levels : with or without data persitency.

   Laurent


-- 
Laurent PHILIPPE  http://lifc.univ-fcomte.fr/~philippe
philippe at lifc.univ-fcomte.fr               Laboratoire d'Informatique (LIFC)
tel: (33) 03 81 66 66 54                                     route de Gray
fax: (33) 03 81 66 64 50                     25030 Besancon Cedex - FRANCE





More information about the gridrpc-wg mailing list