RE: TAP information schema

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.

--Alex

-----Original Message-----
From: Keith Noddle [mailto:ktn-at-star.le.ac.uk] Sent: Thursday, October 11, 2007 4:55 AM To: Doug Tody
Cc: Francois Ochsenbein; Ray Plante; Patrick Dowler; Mark Taylor; Alex Szalay; dal-at-ivoa.net
Subject: Re: TAP information schema

> Good progress has been made

I'm not sure I agree. With the greatest of respect to all involved, this debate is more notable for those not engaged than those who are. If we continue along this track and time line, we risk ignoring the hard and detailed work that went into defining the VOResource family of schemata. We also ignore the investment various VO projects have made in them. Furthermore, without a context (i.e. Use Cases) within which to frame the current Info Schema work, how can we be sure it is either complete or optimal?

It seems logical to me that we elect to use the existing body of approved work to define what content metadata are returned from a TAP V1.0 (note: V1.0) compliant service and move onto the main body of work for TAP V1.0, namely the definition of how we process and manage ADQL queries. The sorts of questions we should be addressing are:

• SOAP or REST?
• Synchronous?
• Asynchronous?
• If asynch:
  • how do we handle return of results?
  • VOSpace?
  • Staging?
  • What are the issues for either?
• etc

If we focus on these and strive to keep TAP V1.0 as simple as possible, we can get it approved and move onto examining the more challenging (and interesting) problems that lie ahead, especially the definition of the Use Cases we are trying to address with Table Access in general.

Keith.

-- 
Keith Noddle                    Phone:  +44 (0)116 223 1894
AstroGrid Project manager       Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy     Mobile: +44 (0)7721 926 461
University of Leicester         Email:  ktn-at-star.le.ac.uk
Leicester, UK   LE1 7RH         Web:    http://www.astrogrid.org