On Wed, Mar 02, 2011 at 11:41:13AM +0100, Michael Hanselmann wrote:
> +To submit jobs, opcodes can return a list jobs, each of which is a list
> +of opcodes (e.g. ``[[op1, op2], [op3]]``), as an instance of a
I think there's a typo above.
> +container class. The job processor will recognize this class and proceed
> +to submit all jobs. The result of the aforementioned callback function
> +for submitting job, a status and job ID/error message (equivalent to the
> +job queue's ``SubmitManyJobs`` function) will be returned to the client.
> +
> +Job submissions can fail for multiple reasons, e.g. a full or drained
> +job queue. Lists of jobs can not be submitted atomically, meaning some
> +might fail while others succeed. The client is responsible for handling
> +such cases.
> +
> +.. highlight:: javascript
> +
> +The result should be encapsulated in a dictionary allowing for future
> +extension. Proposed structure::
> +
> + {
> + "jobs": [
> + (True, "8149"),
> + (True, "21019"),
> + (False, "Submission failed"),
> + (True, "31594"),
> + ],
> + }
It's not clear to me from this what is the exact proposal.
Will these jobs return a dictionary, whereas regular jobs return normal
results? That is not a clear distinction over the JSON transport
encoding.
Maybe we should discuss this a bit offline.
iustin
