[SAGA-RG] Service Discovery

[Andre Merzky]

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