>
> > OBS #8: Client capability negotiation is a new thing in the VO; we
> > currently have have no (little?) software/experience making use
> of it.
>
> Not true; this has been done for some time. A good example of this
> is the TSAP (theory-SSAP) "prototype" from ESAC (Pedro et. al.,
> please correct me if I get any of this wrong). In this case, the
> client application dynamically queries the service for its service
> metadata (using FORMAT=metadata in this older SIAP-based
> implementation), and dynamically adjust the GUI presented to the
> user, so that they can input the parameters of a specific
> theoretical spectral model. There are potentially many cases like
> this, and it is a good example of why clients need access to this
> sort of information, post-discovery of the service.
Well if you have accepted the principle of a getCapabilities()
operation that returns VOResource style metadata, and iff it returns
*all* the metadata about a service then there is a simple
optimization that can make the whole VO work more efficiently - the
client can simply query the registry to find out everything it needs
to know about the service. Registries can ensure that they are up to
date by regularly 'crawling' the registered services, and a client
will get a much faster response than having to separately query each
different service to get service metadata. CEA clients have been
routinely adusting the user interface from service metadata that they
get from the registry for years now.
You could even go further, and with a little more standard metadata in a VOService definition (to take advantage of the other VOSI functionality) e.g. lastPingTime, serviceAliveFlag a client could discover which services are currently alive and make an appropriate selection directly from the registry, without having to contact each one separately. So the registry could would effectively include a service like this http://thor.roe.ac.uk/vomon/status.xml, which takes the approach of providing an independent service to do this important function.
Paul Harrison
ESO Garching
www.eso.org
Received on 2007-04-27Z14:28:13