Hi Pascal, below some answers/comments to the second part of your mail - for the first part I need more time for digestion... :-) Only so much: great that you attempt a SAGA implementation!!! Quoting [Pascal Kleijer] (Dec 14 2006):
General comments and questions. Might be some meat for the public comments as well:
Now we stumbled upon the state machine of the API. The "Unknown" and "New" state are unclear to us. In our opinion when you create a job either with the factory or directly with the constructor of the specific incarnation, we enter the "New" state. The "Unknown" state is now reserved for the very short time the object is instantiated but we directly switch to "New" once the constructor is finished. The principle in OO programming is to have a stable object once you finish constructing it and calling method; if the constructor is not enough to have a stable object you need a factory. So when you get an object back it should be in a stable state, thus the "Unknown" state is superficial in our opinion.
The new state is indeed supposed to reflect a successfull job creation: the job was created by calling job_service.create_job () synchronously. The job instance then has a job description, and methods like run() can be called. saga::job j = job_service.create (job_description); // job is 'New' here, and can be run. However, when the same methid has been called _asynchronously_, the job instance remains uninitialized until the async call returns: saga::job j; // job state is 'Unknown' - cannot be run, yet saga::task = job_service.create_job <async> (&job, job_description); // job state is still 'Unknown' - cannot be run, yet task.wait (); // only now the job instance is initialized, and the state // changes to 'New' - run can be called now. The state diagram contains the method calls which lead to the different states - maybe that is not obvious enough...
Some metrics or attributes or the Job are useless since they come directly from the descriptor, Example: "ExecutionHosts", "WorkingDirectory" or "CPUTimeLimit". Unless you consider that these values might be different from the job description. Or if the job description don't mention them the job can have this values assigned by the back-end. Either case the API documentation should clarify this.
Well, these metrics are not useless, but potentially redundant ;-) as you say, the job_description might not contain the respective values (only 'Executable' is required in jd). Also, you may not have started the job with a job_description, but may have created the instane via list<string> ids = job_service.list_jobs (); saga::job job = job_service.get_job (ids[0]); Also, things like CPUTimeLimit, pwd, or queue may get changed by the backend. Lastly, the metrics are monitorable, so you can get notifictions on such changes. That does not work with the job_description. Does that make sense?
The run_job from the service will not follow the API contract if implemented. Only one parameter can be returned in java. Also the streams are available thought the Job pattern.
Well, you can return an parameter array in Java - that is, AFAIK, the java way to multiple return parameters? But, yes, streams are available anyway. run_job() is a convenience method anyway... I am not sure how that should be rendered in Java... It'll probably be the single most discussed call in the Java bindings ;-)
In the document section 3.8.8 Examples the example at line 16 and 17 is wrong (or the method is overwritten). There should be no string argument. The host should be set in the descriptor.
Yes, indeed! Thanks nice catch - I fixed it in CVS... Cheers, Andre. -- "So much time, so little to do..." -- Garfield