search

aipescience / uws-client

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

uws 1.1: job list filtering #21

Open kristinriebe opened 9 years ago

kristinriebe commented 9 years ago

UWS1.1. services allow to filter the job list by appending corresponding parameters, copied from the standard, section 2.2.1:

1) Filter by phase, e.g. {service-url}/{jobs}?PHASE=EXECUTING

2) {service-url}/{jobs}?AFTER=2014-09-10T10:01:02.000: The server should only list jobs with start times after the given [std:iso8601] time in UTC.

3) {service-url}/{jobs}?LAST=100 The server should list only the given number of most recent jobs ordered by ascending start times.

Filters can be appended, which is to be treated as a union/logical AND. Servers may respond with a 303 redirect to the jobs-url including a LAST-filter, if the job list is too long.

adrpar commented 9 years ago

is there a way to identify if a service speaks UWS1.1 before actually issuing a call? Is there something like HEAD in rest or a version endpoint?

msdemlei commented 9 years ago

There was a discussion on this that I only followed with less than half an eye, and I can't seem to find it on the grid-WG archives (http://mail.ivoa.net/pipermail/grid/), so I guess it must have been in Sesto. Given that, I guess it's fine asking on the list.

kristinriebe commented 9 years ago

Can we use VOSI for this? I got the impression that the /capabilities endpoint is designed to give information about the version, supported features etc.

msdemlei commented 9 years ago

We could, if UWS had a proper, versioned standard-id. Which, as far as I can tell, it hasn't so far. It would have to be defined in the UWS 1.1 document together with a recommendation for how the capabilities element should look like. Not a big deal, I guess, but someone would have to do it.

I'd ask on the gws mailing list first, either way.

adrpar commented 9 years ago

@kristinriebe can you raise this on the mailing list? I will do a try error strategy for the implementation, but proper versioning, even of the standard namespace would be nice (i.e. the existence of http://www.ivoa.net/xml/UWS/v1.1.

kristinriebe commented 9 years ago

I've asked the ivoa-grid list, these are the main results:

adrpar commented 9 years ago

Looks ok for me (partially). Still this requires a call to an UWS endpoint and the retrieval of XML first, to actually know what the client can do. This is a little a hen-egg-problem... but ok.

kristinriebe commented 9 years ago

Update for namespacing: It's actually not going to change, since the update to 1.1 is a minor revision and it is considered more harmful if namespaces change than it helps, so the namespace will stay as http://www.ivoa.net/xml/UWS/v1.0. This should always refer to the latest released version (older versions will be moved somewhere else). Detailed reasons are given in the not yet official note by Paul Harrison: https://code.google.com/p/volute/source/browse/trunk/projects/grid/notes/schema-versioning/schemaVersioning.tex#298. EDIT: In order to not break anything, the "version" attribute is formally "optional" in the UWS 1.1 schema, but in the UWS 1.1 document it will be stated that it must be added nonetheless, so you can rely on this attribute if it's a 1.1 service, but cannot expect it from 1.0-services.

kristinriebe commented 8 years ago

One more comment: there are services that implemented UWS1.1 only partially and thus have the version attribute still set to 1.0. The problem is that the user may know what features are supported, but the uws-client won't use them, because it relies on the version attribute.
I guess we could add a command line option (or set it directly inside main.py?) to force to assume a UWS1.1-service, overwriting the given version-value? This would be valuable if developers want to use the uws-client for testing their services (as we may want to do when implementing UWS1.1 in Daiquiri).