TAP discovery in 1.1

[Patrick Dowler]

On 11 September 2017 at 05:13, Markus Demleitner
<msdemlei at ari.uni-heidelberg.de> wrote:
> Plus: Kinda makes sense, because at least right now you'll have to
> get credentials anyway and hence perhaps don't need to discover the
> services, learning about the access URLs when receiving your
> credentials.  It's also simple to implement, and works flawlessly
> with existing clients.

At least for our services, if you authenticate with an X509
certificate you get access to some features (job listing) that
anonymous users cannot use. You do not need a CADC account for that to
work so it *is* a case where you need to get or have credentials but
not that you need to know about our services specifically.


> PR-TAP-1.1 changes 2: multiple capabilities
> -------------------------------------------
>
> This is orthogonal to problem 1: TAP 1.1 says there should be
> separate capabitites for sync and asyc.  The standard query above
> will then return each set of interfaces twice.  Also, at least I will
> declare a TAP 1.0 capability for quite a while in addition because
> otherwise my service will disappear from legacy clients.  In sum,
> you'll have
>
> <capability standardID="ivo://ivoa.net/std/TAP">
>   ...
>
> <capability standardID="ivo://ivoa.net/std/TAP#async-1.1">
>   ...
>
> <capability standardID="ivo://ivoa.net/std/TAP#sync-1.1">
>   ...

> I wonder: Is there anything we need to have the split sync/async
> capabilities in TAP 1 for?  Is it urgent (e.g., I'm not sure I find
> the ability to declare two different limits on the two endpoints
> proportional to the impacts the whole thing has)?  Are there
> alternatives?
>
> If not, then, frankly, I'd much rather keep a single capability with
> the old ivo://ivoa.net/std/TAP standardID.

The main reason for having these is that you have a set of endpoints
with different names to implement different authentication methods and
the client needs to figure out "which endpoint is the sync endpoint
that supports username/password" (for example).

Now, you could declare an old-style ivo://ivoa.net/std/TAP capability
and rely on the async - sync naming convention. We *used to do that
with paths like this*:

/tap/async
/tap/sync
/tap/capabilities
/tap/auth/async
/tap/auth/sync

but then there is the "must be siblings of the capabilities"
requirement which says we should have

/tap/auth/capabilities

Now we provide these endpoints like this:

/tap/auth-async
/tap/auth-sync

to satisfy the sibling constraint.

That starts to look like /tap and /tap/auth are just two separate TAP
services... so it doesn't really solve the RegTAP situation.

Side note: In the case of X509 client certificates, there is also
potentially a protocol change to https if you want to support both
http and https; one could argue that this isn't really satisfying the
sibling constraint as intended... we could also implement the entire
service under https and only require client cert in some cases (which
devolves to the different-path style above, eg /tap/x509-async and
/tap/x509-sync or something like that).

So, the granularity of the standardID at the feature level is needed
to correctly describe the service capabilities and fits the existing
capabilities model. We have a ton of production code (clients and
services) that use this but it is true that they work as follows:

1. query "registry" by resourceID and find the VOSI-capabilities location
2. get the capabilities document and use that to figure out how to
actually invoke the service

Our client tools are targeted at a specific service so we do not
generally try to solve the part RegTAP does:

0. discovery interesting/useful services (find/pick resourceID)

and I realise that existing clients probably do not perform 1 and 2
before trying to call a service. That's too bad because that part
really works quite well.

PS-I have more I could say but I'll just post this much and continue later...

Pat


-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada