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

[Andre Merzky]

Quoting [Sylvain Reynaud] (Jun 05 2009):
> 
> Andre Merzky a écrit :
>
>> Hi again, 
>
> Hi again,
> 
>>Quoting [Sylvain Reynaud] (Jun 05 2009):
>>>>      
>>>>> - Queue: this attribute makes the job description dependent on the 
>>>>>   targeted
>>>>>   execution site, this information should be put in the URL instead.
>>>>>   
>>>>>        
>>>> Interesting point.  The problem I see is that its hard to
>>>> define a standard way on *how* to encode it in the URL, as
>>>> each URL component (host, path, query, ...) may already be
>>>> interpreted by the backend.
>>>> 
>>>> For example, a globus job manager URL may well look like
>>>> 
>>>> https://some.remote.host:9443/wsrf/services/ManagedExecutableJobService?65e59770-35e1-11da-8810-a04185b6c7ae
>>>> 
>>>> Where would you put the queue?
>>>> 
>>>>      
>>> In JSAGA, such URL is used internally, user gives this URL:
>>> wsgram://some.remote.host:9443/Fork
>>>    
>> 
>> sure, that will mostly work.  The point is however, that we
>> can't assure that it breaks for other backends which require
>> a path specification on the URL.
> 
> But anyway, I think that the main point is not to know if we should put 
> it in the URL or not, it is rather to know if the queue is part of the 
> job description or part of the targeted resource.
> 
> IMHO, the answer is "targeted resource", because if the service 
> discovery extension does not provide this information (either in the URL 
> or in the service_data object), you can not guess it by yourself.

Hi Sylvain, 

yes, excellent description of the problem: it should be part
of the resource specification, not part of the job
description.  Alas, we don't have a resource description
(yet).  BTW, the same holds IMHO for CPUArchitecture for
example, doesn't it?


> >>If encoding the queue in the URL is not an acceptable
> >>solution, then I think the queue should be moved from
> >>attributes of job description to arguments of method
> >>job_service.create_job.
> >>    
> >
> >Thats also an option.  What would be the difference however
> >to keeping it in the job description?  The info arrives at
> >the same call, once in the description, once separate. 
> >  
> The difference is that other attributes in job description do not depend 
> on a particular execution site or a particular grid. Hence the same job 
> description object could be used to run jobs on different hosts (and 
> even on different grids) if it has no attribute "Queue".

Ideally that may be true, but in practice, CPUArchitecture,
OperatingSystem, and others pose similar limitations.

Anyway, don't get me wrong: I think I mostly agree with you
about the problem statement, and the cause.   I am not 100%
about the proposed solution, but that may be just me, being
hesitant to change (I'm known for that I'm afraid)...


>> I understand that having only JSDL approved keys in the job
>> description is a clean solution - but that is mostly for the
>> benefit of the SAGA implementors.  For the SAGA users, that
>> makes not much of the difference, IMHO.
>
> Since they are not in the JSDL specification, these attributes are 
> likely to be put at stake... Moreover, the SAGA specification says these 
> attributes "might disappear in future versions of the SAGA API".
> 
> But I agree, if their usefulness is confirmed, they must be kept.

I think, in the long run, further versions of JSDL, and JSDL
extensions, will make our live much easier...


> >>>>SAGA Name Spaces:
> >>>>================
> >>>>* add a flag to disable checking existence of entry in constructor and 
> >>>>open methods, because the cost for this check is not negligible with 
> >>>>some protocols (then subsequent method calls on this object may throw 
> >>>>an IncorrectState exception
> >>>>if the entry does not exist).
> >>>>    
> >>>>        
> >>>Makes sense.  We could also overload 'Exclusive', which, at
> >>>the moment, is only evaluated if 'Create' is specified.  It
> >>>has the same semantic meaning so (inversed): if 'Exclusive'
> >>>is not specified on 'Create', an existing file is ignored.
> >>>
> >>>Would it make sense to allow Exclusive to be evaluated on
> >>>all c'tors and open calls?
> >>>      
> >
> >Any feedback on this one? :-)
>
> Good idea IMHO, but then I think the name of this flag should be changed 
> to one suitable for both use-cases : exclusive creation and no file 
> existence check.

Ah, well, naming - you are opening a bottomless pit! ;-)  
Any proposal?  I throw in 'FailIfExists' ...


> >I am still not sure about introducing an additional
> >exception here, but that is another issue...
> >  
> Maybe the right exception to be thrown is AuthenticationFailed.
> Then its description should be changed to something like this (page 40) :
> 
> << An operation failed because session could not successfully be used 
> for authentication (none of the available contexts could be used, or can 
> not determine which context to use). >>

I think thats an excellent proposal.


Best regards, 

  Andre.


-- 
Nothing is ever easy.