Hi Steve, Quoting [Fisher, SM (Steve)] (Feb 21 2008):
-----Original Message-----
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?
Not really. The SD part of SAGA should cannot be expected to translate from the real service type in the information system to some language specific one as this would require translation from the language specific name to the langugae neutral name before looking up - and updating this table for each new service or language binding. I find this not very manageable. It is the responsibilty of the service to publish its type in a language independent manner
You are actually the expert here. But my gut feeling would be that it is _very_ difficult to impose a SAGA schema onto service publishers. Also, that would give problems with currently sxisting schemas, and already published services etc. Yes, mapping to specific schemas is certainly difficult - but well, someone _has_ to do it, and I am actually fine with any solution, as long as this problem stays away from the end user.
My favoured way of naming services is reverse DNS style. So the job service would be org.ogf.saga.job. However these names cannot be derived automatically from the spec - as this would give org.ogf.saga.job.job_service. Maybe the best approach is an erratum to the main spec which for each service like thing gives it a unique reverse DNS type name
Well, of course you like that reverse DNS, that is soooo Java ;-)) hehehe Well, naming is always matter of taste, I like the C++ style more, obviously. But I agree, there is no need to make that lnaguage specific. But possible it is. As for managing that mapping list: again I think that a receipe on how these names are formed should be enough. Your reverse DNS name is just the Java class, right? Thats unique, and easily defined... Same can be done in C++ etc. Anyway, I think we are running circles at the moment. We first should agree upon who is doing the mapping, then we can agree on the naming, and the mapping table...
I am sorry I am being so slow to respond. I am trying to do too many things at once - I hope it will be better in April.
np, same here. Hope you are not getting frustrated with the slow progress.... Best, Andre.
Steve
-- "We've got too much time to waste to stand around here doing things." - Tigger