<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Oct 2, 2016 at 11:33 PM, Marco Molinaro <span dir="ltr"><<a href="mailto:molinaro@oats.inaf.it" target="_blank">molinaro@oats.inaf.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">2016-09-30 23:02 GMT+02:00 Walter Landry <<a href="mailto:wlandry@caltech.edu">wlandry@caltech.edu</a>>:<br>
> Patrick Dowler <<a href="mailto:pdowler.cadc@gmail.com">pdowler.cadc@gmail.com</a>> wrote:<br>
>> If people are doing quick queries that respond immediately and they<br>
>> want to minimise connection overhead... TAP-sync? That's what it is<br>
>> for. With TAP-async you have to stage the results someplace, which<br>
>> adds way more latency than an extra connection... so, use TAP-sync!<br>
><br>
> TAP-sync is not appropriate for queries which might have unbounded<br>
> execution time.</div></div></blockquote><div><br></div><div>I can see the use case for that. Sometimes clients don't have enough information about the job being run to make a decent estimate on execution time, so you send it to async to be safe.</div><div><br></div><div>But, I also agree that the cost of doing the extra POST to start the job usually is minor compared to the overhead that comes with async support.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Also, staging happens at the archive in server farms.<br>
> Connections happen over the internet over spotty wifi. The result does<br>
> not even have to be physically written to disk before the user fetches<br>
> it. So I can easily see places where staging is much faster than<br>
> making connections.<br>
><br>
> Moreover, an optimistic user can get by with only 2 connections<br>
> (submit + fetch), because they can tell if they get back a 404 or<br>
> incomplete result. We should not be making our protocols needlessly<br>
> slower.<br>
><br>
>> While TAP-async could mandate support for this, we cannot remove<br>
>> support for the multi-request UWS way (so you need that too) and thus<br>
>> we can't mandate clients use this... which means Brian is right: you<br>
>> can do this and your own client/portal can take advantage of it with<br>
>> no spec change.<br>
><br>
> Mandating support for single-request means that people can rely on it.<br>
> It makes TAP-async faster and easier to use. I do not know the details<br>
> of everyone's implementation, but I would fall off my chair if this is<br>
> actually more work than writing these emails ;)<br>
<br>
</div></div>Probably it's not, but it's a change in standard.<br>
Re-reading Mark's comment, it may push TAP to 2.0.<br>
Not sure it's the right timing.<br></blockquote><div><br></div><div>Maybe the language in UWS should be tightened up too? It could say that job control parameters need to be recognized on job creation unless the implementing protocol disallows it. But again, this would be 1.1 or 2.0.</div><div><br></div><div>Brian</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Marco<br>
<br>
<br>
><br>
> Cheers,<br>
> Walter Landry<br>
</blockquote></div><br></div></div>