StandardInterfaces V0.1

[Tony Linde]

I think I like the cgi params better (but I'm neither a cgi programmer nor a
web service programmer).

Thinking... If a service is registered, we need to specify how it is
invoked, so you specify the call method, cgi or ws, and the invocation
string. The service will be registered under one of the complexTypes,
SkyService, say. Now, does this registry entry include information on how to
call the standard methods available under a SkyService? Or do we assume that
anything registered as a SkyService must supply the standard list of
methods. Or do we allow both: expect the standard methods but allow a
service to supply them in different ways if it wants (in which case its
registry entry must include how to call each of the standard methods). And
if the service includes extra methods, how does the registry entry include a
description of them?

This musing probably belongs in the registry list but if we're looking to
define standard interfaces, it is relevant, or is it?

> and it requires me to 
> look at the metadata to call the standard service.

Does that matter? Most software will use the registry to discover services
so they'll have the entry to hand. If they already *know* about the service
they probably know about how to call the standard methods.

> 2.  a standard named service e.g. if my service is TheService
>     I have theServiceSTDIF which takes params to do the 
> standard services 

I don't understand this Wil. Do you mean that if the standard interface
includes a Metadata method, then a .../cgi-bin/DataLookup service would
create a .../cgi-bin/DataLookupMetadata service? Is that what you mean? If
not, what is STDIF and how would the Metadata method be invoked?

Thanks,
Tony. 

> -----Original Message-----
> From: owner-grid at eso.org [mailto:owner-grid at eso.org] On 
> Behalf Of Wil O'Mullane
> Sent: 23 January 2004 15:46
> To: grid at ivoa.net
> Subject: Re: StandardInterfaces V0.1
> 
> 
> I would like to put a new spec out with something in it ...
> I guess it may always be changed 
> I do not like multiple paths specified in the MEtadata as 
> that measn a new piece of metadata for each standard service 
> and it requires me to 
> look at the metadata to call the standard service.
> 
> I prefer a standard servivce in astandard place i.e. either 
> of the ones I mentioned 
> 1.  params to the CGI like discussed in strasbourg.
> 2.  a standard named service e.g. if my service is TheService
>     I have theServiceSTDIF which takes params to do the 
> standard services or 3. Guys first one below.
> 
> I perfer most 2.
> 
> Can we get a vote on it ?
> 
> wil
> > If we do it this way, how do we associate the CGI call for metadata 
> > etc with the CGI for the basic service?  Should it be like
> > 
> > .../cgi-bin/ServiceXyx/TheActualService
> > .../cgi-bin/ServiceXyz/stdifX
> > .../cgi-bin/ServiceXyz/stdifY
> > etc?
> > 
> > In that case it won't fit trivially to all existing 
> services without 
> > recoding as not all will have the right directory structure.
> > 
> > We could also allow
> > 
> > .../cgi-bin/TheActualService
> > .../cgi-bin/ServiceXyz/stdifX
> > .../cgi-bin/ServiceXyz/stdifY
> > etc
> > 
> > or
> > 
> > .../cgi-bin/AnyPathYouLike1/TheActualService
> > .../cgi-bin/AnyPathYouLike2/stdifX
> > .../cgi-bin/AnyPathYouLike3/stdifY
> > 
> > and sort the paths out in the registry, with a 
> recommendation to use 
> > the same path for all three parts for new work.
> > 
> > However, if we do this we don't allow the standard interfaces to be 
> > coded as part of the basic service, and some authors may 
> prefer to do 
> > that.
> > 
> > Is it better to simplify the writing of CGI services by 
> allowing any 
> > paths or the writing of clients by prescribing the path?
> > 
>