[SAGA-RG] Service Discovery

[Pascal Kleijer]

Dear Steve,

Here are my comments as well on the API. Some of them overlap those of 
Andre, so sorry for the verbatim.

1) The attributes should be handled by the attribute interface. This 
will allow better SAGA L&F integration. Also this might remove the need 
for specific get_vo, get_key & get_values methods. These can be treated 
as attributes of the class. In SAGA, the getters and setters are in 
general covered by the attributes interface and the implementation 
allows specific support for them if needed. The SAGA API should, for the 
time being, go for the minimum common set of functions.
2) I totally agree with Andre that the service should be an interface 
and not a class. Well in a Java binding it might be an all interface anyway.
3) The use of SQL is what made me read the section twice. I think we had 
already a long discussion on the other parts of the API on the usage of 
REGX, wildcards, SQL, etc. We might try to sort this out either by F2F 
or telecon.
4) The name space of this API should be better then "sd". Why not 
"discovery" or something more expressive?

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 ()

So no much worry at the time being.

sub-namespaces are not necessary in the SAGA API because the API is just 
the front end and should remain thin. We expect the implementations that 
are behind to either use their own namespace or use sub-spaces.

Otherwise thanks for your work. If you have a simple demo it is always 
nice to see real "software" and not just real "vapoware" :P
 

Best regards,
Pascal Kleijer

----------------------------------------------------------------
  HPC Marketing Promotion Division, NEC Corporation
  1-10, Nisshin-cho, Fuchu, Tokyo, 183-8501, Japan.
  Tel: +81-(0)42/333.6389       Fax: +81-(0)42/333.6382
  http://www2.nec.co.jp/online-tv/en/introduction/society/met_h.html



Andre Merzky wrote:
> Dear Steve, 
>
> thanks for sharing the document draft!  I do have quite a
> number of comments, so would like to emphasize that I do
> actually like the document, very much so, both in scope and
> approach, and thus hope you won't take the comments as
> criticism - they aren't :-)
>
> I think Shantenu plans a phone call for next Wednesday, in
> particular also to discuss the document.  Would that work
> for you?
>
>
> Comments:
>
>   - it would be good to tie the API package closer to the
>     other SAGA packages.  In particular, it would be very
>     good if the url returned by service.get_url() would
>     explicitely be formed so that it can be used for the
>     construction of saga::job_service, saga::directory,
>     saga::rpc instance etc.  
>
>   - service should be an interface, not a class.  A language
>     binding (e.g. for Java) might render that as interface,
>     but in the langauge independend specs we agreed to model
>     the functional API packages as classes.  Unless I am
>     missing some point here?
>
>   - 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.
>
>   - why is get_attributes on discoverer, but get_values on
>     service?  That seems inconsistent?
>
>   - is it possible to tighten the definition of possible
>     query strings?  For example, the current spec would
>     allow to query with the service filter for
>
>       - type = "ftp"
>       - type = "gsiftp"
>       - type = "gridftp"
>       - type = "remote data"
>
>     How does the end user know what to use?  Does Glue help
>     here (please excuse my ignorance about Glue...)
>
>   - I am still worried that SAGA uses regular expressions in
>     one place, wildcards in other places, and now SQL, too.
>     Not that I know a better approach, or even solution, but
>     we should keep that problem in mind.  I think your
>     statement "uses SQL 92 syntax as if it were part of a
>     WHERE clause" is good: that is something which has a
>     good chance to be reusable by other SQL related
>     packages, should they emerge.
>
>   - I am somewhat confused about the difference between keys
>     and attributes in the service interface/class...  What
>     is the difference, really?  Do you have an example?
>
>   - Is it actually possible to tighten the format of the VO
>     string, e.g. is there some commonly agreed upon format?
>
>   - I think service.get_vo_names should be changed into an
>     attribute, too:  service.get_attribute ("vo_names").
>     Does that make sense?
>
>
>
> Quoting [Fisher, SM (Steve)] (Apr 05 2007):
>   
>> Hi,
>>
>> I attach a first draft of the proposed service discovery SAGA API
>> extension following very closely my presentation at the last GGF. Once I
>> have write access to CVS I will check the source files in.
>>     
>
> Ouch, I think I forgot to take care of this.  My apologies!
> I will be offline over the next week.  Hartmut, Shantenu,
> could you possibly take care of an CVS account at CCT?
>
> Again, my apologies...
>
>
>   
>> We have a prototpye implementation which does not make use of a proper
>> adapter mechanism yet - however we plan to use the SAGA adapter style
>> for the C++. The C++ prototpye is almost complete for the BDII (LDAP)
>> information system and the R-GMA one is not far behind. The performance
>> is good - we can show it at Manchester.
>>
>> We would appreciate any comments - especially identifying those areas
>> where we are not doing things "the SAGA way".
>>     
>
> :-D  I think there aare some of these points above.  Main
> one is about the attributes...
>
> You might want to check the saga::job_description, which is
> an kind of empty class which _only_ implements the attribute
> interface.  It has a lot of the things which you added in a
> similar way.
>
> Also, it would be good to specify the available attributes
> as far a possible.
>
>
>   
>> Incidentally we were surprised that we are only expected to use one name
>> space for the implementation - why are sub-namespaces not permitted -
>> especially for the API extensions? 
>>     
>
> That seemed unneccessary for now.  Imagine a C language
> binding: all name spaces would need rendering the the (flat)
> names of C functions - that can get messy.
>
> Languages like Java, which have a very hierarchical name
> space usually, may add name spaces - I am not sure about the
> neccessity though...
>
>
>   
>> For the Java implementation are we expected to use lower case class
>> names and underscore separated method names?
>>
>> Steve
>>     
>
> Thanks, best regards, 
>
>   Andre.
>
>
>