TAP 1.0: sync vs async

[Gerard]

Dear Doug
Doug wrote:
> 
> I agree with Gerard that async should not be mandated for any 
> of these services - yes there are cases where it needed, but 
> there are also many cases where the data being served and 
> functionality provided are quite constrained and async 
> capabilties are really not an issue.
> The cost/benefit argument is not sufficient.  The VOSI 
> queries are an obvious example of this but it is true for 
> many data services as well.
> 

Doug also wrote:

> As Guy says we already had this discussion some time ago and 
> agreed upon the approach currently in the document (now also 
> the basis for our planning for SIAV2 and other DAL 
> interfaces).  It would be unfortunate to reopen all these 
> issues again at this point in the process.
> 


My position is *NOT* that "async should not be mandated for any of these
services".
My comment dealt with TAP only and my position is that neither synch nor
asynch should be mandated, but that a TAP service 
should support at least one of these.
How this reflects for other DAL Services is a question for later and
possibly to be decided for each service.
It seems clear thought that some people say you can not mandate sync, others
you can not mandate async.
Since these are the two only modes to choose from the only obvious solution
is not to mandate either.
But since a TAP service should do something, one can mandate that aynch OR
async MUST be supported (where OR includes "both").

My second position is that the decision about this should *NOT* be decided
by a technical issue, namely that VOSI queries were so far added to the
synch/ interface and that, since support for VOSI queries is mandatory,
"therefore" support for synch/ queries should be mandatory.

> Whatever we do we do not want to make a special case for this 
> service operation rather than that one.
> To a client application getCapabilities is a service 
> operation just as much as eg queryData.  They should be 
> provided in the same way.

I do not agree with this.
To a client, VOSI and service queries are be very different things, at least
"semantically". 
Therefore they should be siblings.

> Unfortunately people have different models for how these 
> things should work.  One is better than the other in some 
> cases, but in the end it does not make all that much 
> difference, we just need to be consistent and pick the best 
> compromise to satisfy all our use cases.

Obviously people have different opinions.
I am doubtful that there is a "best compromise to satisfy *all* use cases".
We willnever know all use cases.
And it is not at all guaranteed that a use case for SIAP v2, or GDS is
compatible with one for TAP.
I don't see why it would even be necessary to consider these other use cases
now. We are discussing TAP. 
At the moment we want the best design for TAP, where "best" could be
interpreted as the one most people favour. 
So far all the people I spoke to about this issue did actually agree with
the proposal above.
So can we/should we simply vote, something that we did not get to do in
Strasbourg, though that might have been the best avenue.
Pat, Keith, would that be acceptable, desirable?

Cheers

Gerard
> 
> On Thu, 16 Jul 2009, Gerard wrote:
> 
> > Hi Paul
> >> I also support this idea - in fact I would go further (as also 
> >> recently suggested by Tom) and say that the sync and async should 
> >> also be registered as separate Capabilities, and thus 
> potentially on 
> >> totally separate machines, rather than being forced into 
> the single 
> >> URL tree.
> >>
> > I agree, this was missing in the proposal.
> > It would be good to be able to find out explicitly from service 
> > metadata whether one can send sync and/or async queries.
> >
> > Gerard
> >
>