Quoting [Fisher, SM (Steve)] (Feb 20 2008):
Hi,
I was just making the agreed chnages to the SD spec when I relaiszed that you said to use saga::<package>::<class> with package and class according to the implementation language. This won't work easily as means altering the string from the information service or wherever it comes from according to the chosen language. I think that a service type must be independent of the chosen language and so taken from the spec.
I don't think that language dependence is a problem, as I would expect the SAGA implementation to translate that into valid types anyway. In other words: I would not expect a SD _service_ to know about saga::job::service service types, but, for example, about service_type=job_submission service_type=job service_type=job_management service_type=DRMAA service_type=BES etc and the SAGA implementation would translate 'saga::job::service' into the respective values (the SAGA implementation is what shields the application programmer from middleware details, and the exact service type strings are exactly that, middleware details...). Does that make sense to you? Having said that, a lnaguage independent service type in SAGA would certainly also work. It may feel less natural in the one language or the other, but should never break anything...
With this in mind I want to include an example which would be the job_service on p180 of GFD.90. Should this be saga::job::job_service. Given that the package is actually saga.job then perhaps the best name would be saga.job.job_service i.e. <package>.<class> where the package always starts with "saga."
Well, in C++ we agreed on saga::job::service. In the Java bindings, it seems to be something like JobService in the package org.ogf.saga.job. Cheers, Andre.
Steve
-- "We've got too much time to waste to stand around here doing things." - Tigger