[gridrpc-wg] questions about function handles

Hidemoto Nakada hide-nakada at aist.go.jp
Thu Jun 23 10:15:52 CDT 2005


Hello,

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

This is really unfortunate. If you have something to put on the 
table, please send it to this mailing list. We'll discuss on it 
at the F2F meeting and let you report on the discussion.

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

I donot think it is always necessary, if we can assume really good
backend system. Let us assume a real grid-wise file system that is 
capable of automatic caching and expiration. 
On your KMC example, what we need to do is just let the povray server(s)  
know the reference of the data. the data itself might be on the KMC server,
or elsewhere on the grid. There might be even several copies of the data.
The povray server will access the data with the reference and the
grid file system will take care of de-reference of the data and 
data transfer for you. 

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

Yes, the problem is that, which level is suitabl for the gridrpc api to assume.
Let me draft the levels 

level 0: data identification and data transfer
level 1: Global file system without caching and expiration
level 2: Global file system with    caching and expiration

comments?

-hidemoto








More information about the gridrpc-wg mailing list