RE: TAP information schema

From: Alex Szalay <szalay-at-jhu.edu>
Date: Thu, 11 Oct 2007 14:12:10 -0400


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.)
Received on 2007-10-11Z20:12:42