Andre's email
=============
 
  - 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.  
 
This depends upon what is published - if the URL is published
correctly we will return it.

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

That was a mistake in the text - in the SIDL we have the service as an
interface but not in the accompanying text. However if the service is
to implement an attribute interface then it can't itself be an
interface but must become a class - we could of course extend rather
than implement.

The discoverer should be a class returning services.

Incidentally it may makes sense to rename "service" to
"service_description".

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

In the case of the type it is the responsibility of the service
provider, publishing the service to publish a well known service
type. I prefer the service name to take the form of a DNS registered
name - registered by the service provider. e.g. org.globus.gridftp.

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

We really need the power of SQL!

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

The attributes are based on the GLUE attributes. The key/value pairs
are defined by the service publisher. The service publisher is free to
define his own key names.

The key names may clash with the glue attribute names so we cannot use
the attribute interface for both. We favout using the attribute
interface for the glue attributes and retain our current solution for
the key value pairs.

  - Is it actually possible to tighten the format of the VO
    string, e.g. is there some commonly agreed upon format?

In EGEE/gLite/WLCG we are moving towards DNS names again to avoid
clashes. However again the actual names are out of scope. GLUE makes
recommendations but insists upon nothing.

  - I think service.get_vo_names should be changed into an
    attribute, too:  service.get_attribute ("vo_names").
    Does that make sense?

We can do that. We will keep the get_url call however as it is a very
common one.


Pascal's email
==============

    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.

Yes - see above

    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.

Yes - see above

    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.

I don't think it is feasible to get the desired behaviour without SQL
or something similar. We do want the code to be useful in gLite.

    4) The name space of this API should be better then "sd". Why not
    "discovery" or something more expressive?

As we are not allowed to make the namespace visible in the
implementation I don't really care too much what goes in the SIDL as a
name space. What is the justification for not having sub-namespaces
within SAGA as it says in section 2.2.1 of the spec?

    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. For both C++ and
Java I would favour listServices(). Howebver it may be best to just
follow the majority of the existing implementation code.

Steve and Paventhan