Simple Cone Search - starting a revision

[Theresa Dower]

Hello DAL!

Just a quick note to point 2 regarding changing:  

 http://data.center/conesearches?CAT=mycat& to  http://data.center/conesearches/mycat?

Yes, this would be a significant change for two separate MAST ConeSearch architectures, currently registered as ~25 different services handling as many catalogs. We are recently looking into overhauling this anyway, but I am unsure of the timeline.

--Theresa Dower

________________________________________
From: dal-bounces at ivoa.net [dal-bounces at ivoa.net] on behalf of Markus Demleitner [msdemlei at ari.uni-heidelberg.de]
Sent: Thursday, July 13, 2017 7:46 AM
To: dal at ivoa.net
Subject: Re: Simple Cone Search - starting a revision

Hi Marco,

On Tue, Jul 11, 2017 at 04:04:14PM +0200, Marco Molinaro wrote:
> 2 - allowing POSTing to cone search services
> ===================================
> GET or POST for synchronous resources is the same
> for DALI, and letting POST by available to SCS seems
> a direct thing.
>
> However, SCS-1.03 has base URL defined as
> http://<server-address>/<path>?[<extra-GET-arg>&[...]]
>
> thus, in case of POST, where do we set the <extra-GET-args>?
>
> a - leave them as GET args and have a mixed GET/POST
> b - ask, supporting POST, also the extra go to POST data
> c - promote path-params directly in 1.1, removing the
> possibility to have extra-GET-args in SCS base URL
>
> a) seems straightforward, even if not so neat
> b) requires extra work for clients to adapt (apart from server)
> c) breaks a bit current spec, even if we leave current
> base URL as allowed and only discourage it

First let me repeat my basic premise for a point release: we don't
break clients, i.e., 1.0 clients can simply keep operating 1.0 and
1.1 services, and 1.1 clients should not have a hard time talking to
1.0 hosts.  1.1 clients, once they're sure their server is 1.1, are
fine to do extra things, though.

So, I'd say we're free to say what 1.1 services should do when being
POSTed to (except that I suspect that there's already quite a bit of
code POSTing to SCS 1.0 services.  Bonus points if we can avoid
breaking these).

My vote would be that there should be no query parts any more in SCS
1.1 access URLs (i.e., alternative c).  The fixed query parts have
always been a bit hacky.  The trouble we're getting when we're trying
to define how to get to the capabilities is indicative that letting
people hard-code extra arguments was perhaps a well-meaning but still
unfortunate mistake; being able to safely do path manipulations is a
good thing.

Do any of the data centers that use parameters to tell apart
different cone searches forsee that going from

  http://data.center/conesearches?CAT=mycat&

to

  http://data.center/conesearches/mycat?

would break their software in a major way?

> 3 - the capabilities endpoint
> =====================
> Again, without the <extra-GET-args> adding a should to the
> specification would be easy, but how to deal without removing
> the extra args (or, better, without moving them from being
> attached to the base URL)?
>
> Technically, attaching the <extra-GET-args> to /capabilities after
> the server/path/ base can be done, but I don't know if it's a good
> idea, even if considering a cone search (multi-)service serving
> various catalogues that use the extra-GET-args to distinguish
> among them.

Ouch.  I'm sure there needs to be language saying something on this
in DALI *if* we wanted to go there (and I'm not even sure what we'd
say).

Anyway, since we're moving more and more of our orchestration to
/capabilities, its URI must be easily computable; that's why we are
requiring that /capabilities must be a simple sibling of the access
URL in recend standards. That way, a client that needs to know more
about the service can strip off the last path component and append
/capabilities to get there.

Requiring query string manipulations to make this work is
error-prone (not to mention that it goes against the VOSI spirit).

I'd say consideration (3) is a strong argument for (2c) above.

           -- Markus