StandardInterfaces V0.1

[Wil O'Mullane]

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