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