Ubuntu Manpage: stilts-tapresume - Resumes a previous query to a Table Access Protocol server

NAME

       stilts-tapresume - Resumes a previous query to a Table Access Protocol server

SYNOPSIS


       stilts tapresume [joburl=<url-value>] [compress=true|false] [poll=<millisec>] [progress=true|false]
                        [delete=finished|never|always|now] [ocmd=<cmds>]
                        [omode=out|meta|stats|count|checksum|cgi|discard|topcat|samp|tosql|gui] [out=<out-
                        table>] [ofmt=<out-format>]

DESCRIPTION

       tapresume can resume monitoring and data retrieval from an asynchronous Table Access Protocol query which
       has  already  been  submitted.  TAP is a Virtual Observatory protocol. Such a pre-existing query may have
       been submitted by the tapquery command or by some completely different mechanism. It essentially does the
       same job as tapquery but without the job submission stage. It waits until the query  has  completed,  and
       then  retrieves  the  table result and processes it in accordance with the supplied parameters. The query
       may or may not be deleted from the server as part of the operation.

OPTIONS

joburl=<url-value>
The URL of a job created by submission of a TAP query which was created earlier and has not yet
been deleted (by the client) or destroyed (by the server). This will usually be of the form <tap-
url>/async/<job-id>. You can also find out, and possibly retrieve results from the job by pointing
a web browser at this URL.

compress=true|false
If true, the service is requested to provide HTTP-level compression for the response stream (Ac‐
cept-Encoding header is set to "gzip", see RFC 2616). This does not guarantee that compression
will happen but if the service honours this request it may result in a smaller amount of network
traffic at the expense of more processing on the server and client.

poll=<millisec>
Interval to wait between polling attempts, in milliseconds. Asynchronous TAP queries can only find
out when they are complete by repeatedly polling the server to find out the job's status. This pa‐
rameter allows you to set how often that happens. Attempts to set it too low (<50) will be reject‐
ed on the assumption that you're thinking in seconds.

progress=true|false
If this parameter is set true, updates on the status of the asynchronous UWS job are reported to
standard output as they become available. This parameter is ignored in synchronous mode.

delete=finished|never|always|now
Determines under what circumstances the UWS job is to be deleted from the server when its data is
no longer required. If it is not deleted, then the job is left on the TAP server and it can be ac‐
cessed via the normal UWS REST endpoints or using tapresume until it is destroyed by the server.

Possible values:

* finished: delete only if the job finished, successfully or not

* never: do not delete

* always: delete on command exit

* now: delete and return immediately

ocmd=<cmds>
Specifies processing to be performed on the output table, after all other processing has taken
place. The value of this parameter is one or more of the filter commands described in SUN/256. If
more than one is given, they must be separated by semicolon characters (";"). This parameter can
be repeated multiple times on the same command line to build up a list of processing steps. The
sequence of commands given in this way defines the processing pipeline which is performed on the
table.

Commands may alternatively be supplied in an external file, by using the indirection character
'@'. Thus a value of "@filename" causes the file filename to be read for a list of filter commands
to execute. The commands in the file may be separated by newline characters and/or semicolons, and
lines which are blank or which start with a '#' character are ignored. A backslash character '\fR'
at the end of a line joins it with the following line.

omode=out|meta|stats|count|checksum|cgi|discard|topcat|samp|tosql|gui
The mode in which the result table will be output. The default mode is out, which means that the
result will be written as a new table to disk or elsewhere, as determined by the out and ofmt pa‐
rameters. However, there are other possibilities, which correspond to uses to which a table can be
put other than outputting it, such as displaying metadata, calculating statistics, or populating a
table in an SQL database. For some values of this parameter, additional parameters (<mode-args>)
are required to determine the exact behaviour.

Possible values are

* out

* meta

* stats

* count

* checksum

* cgi

* discard

* topcat

* samp

* tosql

* gui
Use the help=omode flag or see SUN/256 for more information.

out=<out-table>
The location of the output table. This is usually a filename to write to. If it is equal to the
special value "-" (the default) the output table will be written to standard output.

This parameter must only be given if omode has its default value of "out".

ofmt=<out-format>
Specifies the format in which the output table will be written (one of the ones in SUN/256 -
matching is case-insensitive and you can use just the first few letters). If it has the special
value "(auto)" (the default), then the output filename will be examined to try to guess what sort
of file is required usually by looking at the extension. If it's not obvious from the filename
what output format is intended, an error will result.