Simple Cone Search - starting a revision

[Pierre Fernique]

The same point for VizieR.

All VizieR CS actually follows this kind of template, mixing extra 
parameters before and after the question mark:
http://vizier.u-strasbg.fr/viz-bin/votable/-A?-out.all&-source=CATID&...

Unfortunately, Gilles Landais, in charge of VizieR at CDS, is presently 
in vacation. But I'm quite sure that the impact of such a modification 
will be large, not only for VizieR server code, but also for all VO and 
no VO clients/libraries which are using this CS VizieR access for years.

The solution 2.a) appears more conservative and pragmatic.

Cheers
Pierre Fernique

Le 13/07/2017 à 16:48, Theresa Dower a écrit :
> 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