Andre Merzky a écrit :
Quoting [Thilo Kielmann] (Jun 04 2009):
Dear Sylvain,
I raised it at OGF23 (see slide 34 of my talk).
sorry, I must have missed this within your list of modifications.
Our deviations from the SAGA specification are listed here http://grid.in2p3.fr/jsaga-dev/SAGA-delta.html
I just had a look. This is quite a list. Would you, from your experience as of today, recommend more/some/all for inclusion in a "fixed" SAGA standard?
Dear Sylvain,
we should have given you more detailed feedback on your list earlier on *blush* Most of the items have been discussed at one point or the other, however. Here is a detailed list. Thilo is right: we should resolve the items soonish.
Dear Andre, Thanks for this detailled feedback on our deviations from the SAGA specification. Here are some answers, inline in this mail. My proposals for a "fixed" SAGA standard will come in a separate mail.
AmbiguityException:
The spec does not define if saga::exceptions can be extended. I guess legally that can only happen outside the saga namespace, so, IMHO, that is a conflict. I think the type of exception is not really a problem since users can catch it as a NoSuccessException, but the difference in behavior for authentication may break compatibility between SAGA implementations... (see next mail)
OTOH, its closely related to the implementation semantics (retry), so, to some extent, its an implementation detail. Not sure how to handle in the spec.
BTW: 'avoid account locking' is an interesting use case...
context.toString():
Thats a language binding issue. In C++, we also have a get_string () on the URL, for example.
I agree.
URL:
Query interpreted as adaptor parameters: thats an implementation specific behaviour: SAGA does not define URL semantics. It breaks application portability though I assume.
Yes, I also think so. We try to avoid using this, but some protocols require additional information.
FLAGS_BYPASSEXIST=4096
I would think this is better solved on configuration level, in Java as a saga.property for example?
I don't think so because this depends on use-case, hence on user's code. Moreover, the user should be aware that he is changing the default behavior.
Again, that breaks portability.
Yes, that's why I want to propose it for inclusion in a "fixed" SAGA standard (see next mail)
additional method copyFrom():
I don't understand the use case for this. How is
saga::file f (url_1); f.copy_from (url_2);
different from
saga::file tmp (url_2); tmp.copy (url_1); saga::file f (url_1);
Is it about saving one line of code, and one temp object?
No, it was for optimizing file transfer from many-to-one locations without managing a pool of connections. But I plan to remove this method and do this another way.
additional method getLastModified():
as discussed, should make it into the spec.
OK.
NSEntry.remove() allows !Recursive flag:
The is actually in the spec, as
saga::directory d (url); d.remove (0); // 0: empty flag set, i.e. Recursive is not set
I think what you want is to change the semantics, from
- a ’BadParameter’ exception is thrown if the entry is a directory and the ’Recursive’ flag is not set.
- a ’BadParameter’ exception is thrown if the entry is a *nonempty* directory and the ’Recursive’ flag is not set.
Would that solve your use case?
Yes (my use-case is: "how to implement rmdir").
Job description JobName attribute added
This is not in the spec. Well, we had to draw a line somewhere, and as it was optional in JSDL, and noone really had a compelling use case, it was left out. Do you have applications which require that one?
I was using it with "allocateResource" (see end of this mail), but I am not sure I will still need it in the future...
Job description CPUArchitecture attribute added
has been added in the spec meanwhile
Job description OperatingSystemType attribute added
has been added in the spec meanwhile
That's not the point (see next mail).
Job description JobStartTime and JobContact attributes not supported
That is no problem.
(see next mail).
job attribute 'NativeJobDescription' added
I assume that is a read-only attribute?
Yes.
What is the use case for this one? Debugging?
Yes. I don't expect it to be included in the specification.
job.sub_state metric added:
saga::job already has a metric 'job.state_detail' - what is the difference?
job.state_detail can not be used in a uniform way because its values depends on each middleware. (see next mail)
method allocateResource added:
Is that method on job, or on the job_service? What is the semantics?
I think that this would not go into the job managament in SAGA, but rather into the resource discovery/management extension Thilo's group is working on (within XtreemOS). You might want to check with them if their extension proposal fits your requirements...
The goal was not to do resource discovery in SAGA, but to enable doing it outside of SAGA. But there are ways to do that without breaking portability, and I plan to remove this method. Best regards, Sylvain