[SAGA-RG] Service Discovery

[Andre Merzky]

Hi Pascal, Steve,

Quoting [Pascal Kleijer] (Apr 16 2007):
> 
> Dear Steve,
> 
> Here are my comments as well on the API. Some of them overlap those of 
> Andre, so sorry for the verbatim.
> 
> [...]
> 
> 2) I totally agree with Andre 

Ha, but that is only by chance, because...

> that the service should be an interface 
> and not a class. Well in a Java binding it might be an all interface anyway.

... I wanted to say it should be a class, not an interface!
Steves document has it as an interface, sorry for the
confusion!

Anyway, yes, the Java language binding MAY render it as an
interface, depending on how other SAGA classes are rendered
in the Java bindings...


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

On the other hand, we have directory.list(), and
job_service.list(), so a discoverer.list() might be the
better choice?  Or should it be service_discoverer then?

Naming... *sigh*  bottomless pit...

Cheers, Andre.


> 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.
-- 
"XML is like violence: if it does not help, use more."