search

aipescience / uws-client

IVOA UWS service command line client
Apache License 2.0
11 stars 9 forks source link

WAIT parameter for UWS 1.1 blocking behaviour #33

Closed kristinriebe closed 8 years ago

kristinriebe commented 8 years ago

This includes the additional optional parameter "--wait" for uws job show that can be used when requesting job details from a UWS1.1 server. The server is expected to block and return if a) the job changed its phase b) the specified time is over c) the server times out or stops blocking for some other reason (e.g. too many blocking requests)

If additionally a phase is given with "--executing", "--queued" or "--pending" (nothing else allowed), then server should return immediately, if the job is not in the specified phase. See section 2.2.1.2 Blocking Behaviour of the UWS standard.

Example: uws job show [id] --wait 30 --executing Waits for 30 seconds for the job with id [id], but returns immediately if phase of job is not executing.

kristinriebe commented 8 years ago

Instead of using
[...] --wait 30 --executing
etc. for the wait phase, we could also use
[...] --wait 30 --phase executing
etc. This would have the advantage that we can give a more meaningful error message, if a wrong (non-active) phase is given (e.g. 'phase is not supported, only ... allowed'). A 'wrong' phase in this sense is any phase other than EXECUTING, QUEUED or PENDING. Currently, if e.g. --completed is provided, argparse complains about an unrecognized argument. I tried to catch this by experimenting with argparse.REMAINDER, but it seemed buggy. Any opinions on that?

adrpar commented 8 years ago

I'm fine with the phase keyword

adrpar commented 8 years ago

if my small comments are addressed, you can consider this approved.