Andre Merzky wrote:
Hi Graeme,
Quoting [Graeme Pound] (Mar 07 2006):
I am afraid that I find this a little bizarre.
As I understand it; job_service.get_self() returns a representation of the _local_ client application which has instantiated the job_service object (is that correct?). This would allow the client application to perform operations upon itself via the 'job' interface.
Exactly! :-)
We call those applications to be 'Grid aware', but I am not sure if that is a good term. However, the app 'knows' it is running in a Grid, and can actively perform actions, also on itself. For example it can migrate itself, if there is need to do so (think agents). Also, it can spawn copies of itself, to perform some partial analysis (it gets the job object for self, it gets the job description from that, and resubmits that description with some changed parameters: ergo the app gets cloned).
I think taht the concept opens a range of very dynamic scenarios...
Andre, I really do not like this concept. It has been added as an aside to the jobmanagement package but opens a large can of worms. The practical problems that this poses to implementations of the API are huge. For starters; each SAGA implementation must provide an implementation of the Job interface specific to the resource which that implementation targets, a large amount of additional code would be required to perform operations on the _local_ client application. This must be beyond the scope of the jobmanagement package, which is otherwise well defined. Operations on the local client application can only be in a fraction (if any) of the SAGA use cases. This sort of thing departs from the concept of a *simple* API for the Grid. Graeme