[SAGA-RG] missing(?) method reporting last modification time

[Sylvain Reynaud]

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