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