gavo.protocols.useruws module

Support for UWSes defined in user RDs.

To understand this, start at makeUWSForService.

class gavo.protocols.useruws.UserUWS(service, jobActions, parameterGrammar)[source]

Bases: gavo.protocols.uws.UWSWithQueueing

A UWS for “user jobs”, i.e., generic things an a core.

These dynamically create job classes based on the processing core’s parameters. To make this happen, we’ll need to override some of the common UWS functions.

Note: For async operation (without a custom UWS), you can only have uploads in the upload parameter.

getIdsAndPhases(*args, **kwargs)[source]

returns pairs for id and phase for all jobs in the UWS.

phase, last, after are the respective parameters from UWS 1.1.


returns the handling URL for the job with jobId.

You must override this in deriving classes.

jobdocPreamble = "<?xml-stylesheet href='/static/xsl/useruws-job-to-html.xsl' type='text/xsl'?>"
joblistPreamble = "<?xml-stylesheet href='/static/xsl/useruws-joblist-to-html.xsl' type='text/xsl'?>"
class gavo.protocols.useruws.UserUWSJobBase(props, uws, writable=False)[source]

Bases: gavo.protocols.uws.UWSJobWithWD

The base class for the service-specific user UWS jobs.

(i.e., the things that the UserUWSJobFactory spits out)

class gavo.protocols.useruws.UserUWSTransitions[source]

Bases: gavo.protocols.uws.ProcessBasedUWSTransitions

The transition function for user-defined UWSes.

queueJob(newState, wjob, ignored)[source]

puts a job on the queue.


returns a UserUWS instance tailored to service.

All these share a jobs table, but the all have different job classes with the parameters custom-made for the service’s core.

A drawback of this is that each UWS created in this way runs the job table purger again. That shouldn’t be a problem per se but may become cumbersome at some point. We can always introduce a class Attribute on UserUWS to keep additional UWSes from starting cron jobs of their own.


returns a class object for representing UWS jobs processing requests for service