TAP information schema

Alex Szalay szalay at jhu.edu
Thu Oct 11 11:12:10 PDT 2007


I would expect that we want in most of the cases to use a local VOSpace so
that with large amounts of data we are not subject to network timeouts and
interruptions, and then the service would just provide the URI to the
VOSpace object that is the output.

Then the receiving end can retrieve at will, possibly trying multiple times
if that is what it takes.

--Alex

-----Original Message-----
From: owner-dal at eso.org [mailto:owner-dal at eso.org] On Behalf Of Patrick
Dowler
Sent: Thursday, October 11, 2007 12:53 PM
To: dal at ivoa.net
Subject: Re: TAP information schema


I also agree 100% with this -- need both sync and async and the output of
the 
async should go to a VOSpace...

Can one just specify that the output is to some combination of a service
type 
(soap, rest, etc) and a service endpoint (URL) that makes ? Would that 
include VOSpace and other (unknown) interfaces? The reason I am asking is 
that for VOSpace 1.x the destination is a SOAP web service but there was
lots 
of talk about VOSpace 2.0 being REST (eg more vanilla http). 

Also, is either of sync or async an optional capability? My feeling is that
at 
a minimum sync is required and async is optional, but anyone with a decent 
sized database is going to implement async. 

Further, I think a TAP service should have the option of refusing to execute
a 
query in sync mode and telling the caller that async must be used. We would 
need to specify exactly how the service makes this known, but in the general

case a service may decide after seeing the query itself so I think this is a

sort of result or error message (actually more like an http redirect) that 
clients will have to deal with.

pat

On 2007-10-11 04:27, Alex Szalay wrote:
> My 2 cents on Sync/Async:
>
> we desperately need this feature to build the next generation scalable
> services. Not to have this is simply not an option in my opinion
>
> I think that most of the hard work that went into VOSpace was with this
> feature in mind, so I would strongly recommend that the default proposal
is
> to use VOSpace for async messaging
>
> We still may want to retain the ability to do sync returns, especially for
> small requests (like metadata). It would increase the responsiveness of
our
> services if for such requests we could expect an immediate response.


-- 

Patrick Dowler
Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada                  | Gouvernement du Canada
5071 West Saanich Road               | 5071, chemin West Saanich
Victoria, BC                                  | Victoria (C.-B.)





More information about the dal mailing list