[SAGA-RG] Service Discovery

[Andre Merzky]

Quoting [Fisher, SM (Steve)] (May 07 2007):
> 
> The point of service discovery is to locate a service.  Any SAGA call
> which needs to connect to a remote service and that makes this explict
> can make use of SD. For example the RPC of 3.13 requires the URL of the
> service provider. Also the job_service requires as input the contact
> string for the resouce manager. Servide discover provides these URLs. I
> haved added a sentence or two explaining this.

Yes, that is what I meant.  Having that statement in the doc
helps to understand the relation between the documents.
Thanks!


> > >   - we do have an attribute interface (doh! ;-) in the SAGA
> > >     core API spec.  I think it would be best to use that
> > >     interface for the service interface/class.
> > > 
> > > Yes - there seems to be no problem with that in principle for the
> > > service attributes.
> > > 
> > >   - why is get_attributes on discoverer, but get_values on
> > >     service?  That seems inconsistent?
> > > 
> > > Discoverer has get_attribute_names() method which will 
> > return an array
> > > of all possible standard names deliverable by the existing 
> > information
> > > system adapters.  All services have the same set so associating this
> > > data with the discoverer rather then the service seems to 
> > make sense.
> > 
> > If the attribute set is fixed, then using the
> > saga::attribute interface in the service (or
> > service_description) instances would be easy.  The document
> > should specify what attributes are available IMHO.  Again,
> > technically this looks more and more like the
> > saga::job_description class, and IMHO it would be good to
> > design the service(_description) class the same way.
> 
> If we want to use the attribute interface, and I agree that we should,
> perhaps the best way is to have two extra classes both of which
> implement the Attribute interface. Then you can say, where s is a
> service_description:
> 
>   s.get_data().get_attribute("some key value in the key value pair")
> 
> or 
> 
>   s.get_glue().get_attribute("some predefined 'glue' attribute")
> 
> This avoids the name clash problem - though we need a better name than
> get_glue()
> 
> I would like people's agreement that this is the right way to go before
> doing this. It makes things simepler but adds 2 trivial classes. I think
> I like it!

Interesting point!  Its a tradeoff, as you say.  I am not
sure if I like it personally, but it looks like a clean
solution, and if others are ok with it we should go that
route I guess.  


> > 3. given the two (possibly minor) disadvantages above, and
> >    no percieved need for additional name spaces, we decided
> >    against their use.
> 
> I think it was a bad choice - but I can live with these rules

:-)


> > >     The API specification document and the language bindings L&F are
> > >     different things. In the document we have a more C style
> > >     coding. When the implementation is done we should use language
> > >     specifics:
> > > 
> > >     - list_services() -> in C: list_services()
> > >     - list_services() -> in C++: ListServices()
> > >     - list_services() -> in Java: list ()
> > > 
> > > Sometime rather soon we should define these styles. 
> 
> So are we free to add namespaces - like all other large packages ;-)

:-P

Yes, but should be done in sync with the language bindings
for the saga core spec...

Thanks!  cu tomorrow, Andre.

> Steve





-- 
"XML is like violence: if it does not help, use more."