Peter G Lane wrote:
Well, we were using the term "command" to indicate the Job Interface Operations described in Section 5.2. Basically, for administrative purposes it could be useful if the sequence of operations performed on each job is logged and could be accessed in some way. But probably this operation is not strictly related to job submission and should be considered in a separate interface.
Ok. I personally can't come up with a use case, but that doesn't mean one doesn't exist. Care to elaborate why this is useful? Do you not trust that the service will do what you tell it to do?
Probably it is not a very frequent use case; anyway, if users are allowed to authorize other users to issue commands (i.e., suspend, resume, cancel operations) on their own jobs, then it may be useful to inspect the list of commands which have been issued to a given job, as they may have not been given by the job owner. This feature may be useful for tracking down problems (for debugging purposes). Perhaps, rather than making such "job command list" property mandatory, we may use the "Extensibility" element which is cited in the ESI document on section 5.1? Moreno. -- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35100 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277047 WWW : http://www.pd.infn.it/~marzolla Fax : +39 049 8756233