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