<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 2018-09 -13, at 00:01, Patrick Dowler <<a href="mailto:pdowler.cadc@gmail.com" class="">pdowler.cadc@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class="gmail_default" style="font-size:small"><br class=""></div><div class="gmail_default" style="font-size:small">On the whole topic of base URL vs usable endpoints:<br class=""></div><div class="gmail_default" style="font-size:small"><br class=""></div><div class="gmail_default" style="font-size:small">I have been convinced for a long time that the whole approach we took in TAP-1.0 (8+ years ago) was wrong. We did specify that TAP has both sync and async query execution but we tried to pretend that it was one thing instead of two things. VOSpace has several different endpoints that behave differently and they are separate capabilities. If sync and async were just treated as separate capabilities from the start we would not have this problem and we don't have this problem with any other services. <br class=""></div><div class="gmail_default" style="font-size:small"><br class=""></div><div class="gmail_default" style="font-size:small"><div style="font-size:small;display:inline" class="gmail_default"></div>On Wed, 12 Sep 2018 at 09:17, Paul Harrison <<a href="mailto:paul.harrison@manchester.ac.uk" target="_blank" class="">paul.harrison@manchester.ac.uk</a>> wrote:</div><div class="gmail_default" style="font-size:small">> <div style="font-size:small;display:inline" class="gmail_default"></div>and blurs the distinction about what *the* URL of a service is <br class=""></div><div class="gmail_default" style="font-size:small"><br class=""></div><div class="gmail_default" style="font-size:small">In my mind this idea is wrong and has always been wrong -- there is no *the* URL of a (TAP) service that is directly usable (eg that you can POST to) -- but we (DAL-WG and TAP-1.0 authors) had to make compromises to get TAP-1.0 to REC. We got the cardinality of service-capability-interface-accessURL wrong. It is more complicated than that because you have to just know to append one more special strings to the path to create usable URLs. That makes TAP special, which is sad when VOSI-capabilities is perfectly capable of describing endpoints so you don't need bespoke solutions and knowledge and we have proven that one can write and use a generic capabilities client to work out all the details. <br class=""></div><div style="font-size:small" class="gmail_default"></div><div style="font-size:small" class="gmail_default">I am not arguing that it is impossible to comply with VOSI and DALI and keep a facade of "the URL" in TAP-1.1, but all the things needed to do that and avoid fixing the mistakes of TAP-1.0 make TAP more special and bespoke and less like the standard patterns in other services and the spirit of upstream standards. That means more text, more unforeseen consequences of that text, and less flexibility to use other standards to the fullest. It also means more code specific to TAP. <br class=""></div></div></div></blockquote><div><br class=""></div><div>If we take the “functional" approach that I was advocating earlier in this thread and use curl as a lowest common denominator “dumb” client then only the ParamHttp interface type accessURL fits the bill as an endpoint that you can POST to and get the answers back directly - there is already the precedent of the WebBrowser interface type for which at best it is might be possible to scrape the web page to see how to resubmit the parameters to get the answer and the UWS async interface similarly does not directly give the answers after the initial POST. Therefore my argument is that having to make a trivial addition to the starting URL is much less than the effort of getting the final answer out, and there is not the uniformity of “directly useable” URLs amongst the VO standards that you are suggesting.</div><div><br class=""></div><div>What I do agree with is that it is anomalous to label the base URL interface of the TAP service as paramHTTP as that should stand for the “curl usable” interface - again earlier in the thread I suggested that a new interface type be created called “std” that simply means the URL behaves as described in the standard e.g. as for TAP 1.0</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-size:small" class="gmail_default"><br class=""></div><div class="gmail_default" style="font-size:small">If you still disagree with my claim that there is no "the URL to a TAP service" and there doesn't need to be one, then stop reading now because the rest is about how to fix things.<br class=""></div></div></div></blockquote><br class=""></div><div>Well I do and as Mark has pointed out as well as the arguments presented above registry searches become much more difficult with more interfaces registered.</div><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">On 2018-09 -12, at 18:49, Patrick Dowler <<a href="mailto:pdowler.cadc@gmail.com" class="">pdowler.cadc@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-size: small;"><br class=""></div><div class="gmail_default" style="font-size: small;">On duplicating the VOSI-capabilities deployment: sure you can do that but it makes the service deployment more complicated and means service providers have to write more tests to verify their service is working correctly. And when they register the service in an IVOA registry, which accessURL do they put? Obviously any would do since they are redundant, but someone has to document that and people have to understand that. It's smelly and it is not in the spirit of the DALI sibling rule which is that service endpoints are flat and not heirarchical.</div><div class="gmail_default" style="font-size: small;"><br class=""></div></div></div></div></blockquote><br class="">
</div><div class="">I really do not believe that it makes deployment more difficult (but anyway these suggestions are also at least equally motivated by making life easier for clients of the services). There are two separate (but identically structured) trees one authenticated. You could argue (and we are!) that you just run the same integration test suite twice pointing at two different base URLs….</div><div class=""><br class=""></div><div class="">The registration is simple as Mark showed (with the proviso, as above, that I agree that vs:ParamHTTP is not really appropriate)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span style="font-family: Monaco; font-size: 12px;" class=""> <capability standardID="</span><a href="ivo://ivoa.net/std/TAP" style="font-family: Monaco; font-size: 12px;" class="">ivo://ivoa.net/std/TAP</a><span style="font-family: Monaco; font-size: 12px;" class="">"></span><br style="font-family: Monaco; font-size: 12px;" class=""><br style="font-family: Monaco; font-size: 12px;" class=""><span style="font-family: Monaco; font-size: 12px;" class=""> <!-- Unauthenticated TAP base URL --></span><br style="font-family: Monaco; font-size: 12px;" class=""><span style="font-family: Monaco; font-size: 12px;" class=""> <interface xsi:type="vs:ParamHTTP" role="std" version="1.1"></span><br style="font-family: Monaco; font-size: 12px;" class=""><span style="font-family: Monaco; font-size: 12px;" class=""> <accessURL use="base"></span><a href="http://example.net/myTAP</accessURL>" style="font-family: Monaco; font-size: 12px;" class="">http://example.net/myTAP</accessURL></a><br style="font-family: Monaco; font-size: 12px;" class=""><span style="font-family: Monaco; font-size: 12px;" class=""> </interface></span><br style="font-family: Monaco; font-size: 12px;" class=""><br style="font-family: Monaco; font-size: 12px;" class=""><span style="font-family: Monaco; font-size: 12px;" class=""> <!-- Authenticated TAP base URL --></span><br style="font-family: Monaco; font-size: 12px;" class=""><span style="font-family: Monaco; font-size: 12px;" class=""> <interface xsi:type="vs:ParamHTTP" role="std" version="1.1"></span><br style="font-family: Monaco; font-size: 12px;" class=""><span style="font-family: Monaco; font-size: 12px;" class=""> <accessURL use="base"></span><a href="http://example.net/myTAP-auth</accessURL>" style="font-family: Monaco; font-size: 12px;" class="">http://example.net/myTAP-auth</accessURL></a><br style="font-family: Monaco; font-size: 12px;" class=""><span style="font-family: Monaco; font-size: 12px;" class=""> <securityMethod standardID="</span><a href="ivo://ivoa.net/sso#BasicAA" style="font-family: Monaco; font-size: 12px;" class="">ivo://ivoa.net/sso#BasicAA</a><span style="font-family: Monaco; font-size: 12px;" class="">"/></span><br style="font-family: Monaco; font-size: 12px;" class=""><span style="font-family: Monaco; font-size: 12px;" class=""> </interface></span><br style="font-family: Monaco; font-size: 12px;" class=""><br style="font-family: Monaco; font-size: 12px;" class=""><span style="font-family: Monaco; font-size: 12px;" class=""> </capability></span><br style="font-family: Monaco; font-size: 12px;" class=""></div><div class=""><br class=""></div><div class=""><div class="">searches in the registry can be simple and only one URL returned if you specify that you do not want authenticated - this is all without breaking any ‘rules’ and keeping current practice. </div></div><div class=""><br class=""></div><div class="">Paul.</div><div class=""><br class=""></div><div class="">p.s. Another suggestion that I am slightly loath to make as I think it seems a bit hacky - TAP 1.1 could always specify that the baseURL redirects to the sync endpoint - then there could even be no argument against vs:ParamHTTP as the interface type in the above capability.</div><div class=""><br class=""></div><div class=""><br class=""></div>
<br class=""><div class=""><br class=""></div></body></html>