Error column in VOResource

[Tony Linde]

As I keep saying, the coupling is an issue of implementation, not design. We
design the registry interface so that it is a one-stop shop for all metadata
but if one implementation gets the metadata from the resource every time it
is asked and another caches that metadata, it is transparent to the calling
application.

> Making the registry a one-stop shop for metadata demands a 
> tight coupling with the services they describe.  Any change 

I don't see why - the registry only needs to know how to ask for the
metadata and how to return it to the calling app. We will have a standard
way of getting the metadata (from Wil's proposal for a standard baseline for
all services), a standard representation (VOResource which includes the
DM-based schema) and a standard way for apps to get that metadata (RI spec).
This is about as loose a coupling as I can think of.

And if it *did* require tight coupling, all the more reason to put all this
processing into the registry, otherwise you end up with every single
application having to be tightly coupled to every resource - but this is not
the case.

Making the registry the source of all metadata means that all applications
only have to manage one interface right down until they select the service
they want to invoke - they don't have to each and every one be coded to fish
around lots of services looking for the metadata they want.

T.

> -----Original Message-----
> From: Ray Plante [mailto:rplante at ncsa.uiuc.edu] 
> Sent: 18 May 2004 16:51
> To: Tony Linde
> Cc: registry at ivoa.net
> Subject: RE: Error column in VOResource
> 
> On Tue, 18 May 2004, Tony Linde wrote:
> > the registry is a one stop shop for all metadata.
> 
> I disagree with this statement in general.  Besides various 
> pratical reasons of scaling and scope, there is an issue of 
> volitility.  
> 
> Making the registry a one-stop shop for metadata demands a 
> tight coupling with the services they describe.  Any change 
> in the service must be reflected back into the registry.  If 
> the registry is simply about discovering services, the 
> coupling is looser, and the service is more flexible to 
> changes in implementation.  
> 
> It can be argued that the tighter the coupling, the more 
> costly the system in terms of software development and 
> coordination of people.  A tightly coupled design may be 
> appropriate for a particular VO project that can manage that 
> coordination; however, it's less appropriate for the IVOA as 
> a whole.  
> 
> It's an interesting issue that I expect we'll learn more 
> about with experience.
> 
> cheers,
> Ray
> 
>