No subject

Paul Harrison pharriso at eso.org
Fri Apr 27 05:27:51 PDT 2007


>
> > 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



More information about the dal mailing list