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