[saga-rg] 1.4 version of the spec [part2]

[Graeme Pound]

Andre,

Your reply did not go to the mailing list.

Graeme


Andre Merzky wrote:
> Quoting [Graeme Pound] (Feb 24 2006):
>> Andre,
>>
>> Further comments on revision 0.4 (not all negative ;-)
> 
> Phew! :-)
> 
> 
>> Thanks
>>    Graeme
>>
>>
>>  #1 submitJob() has been renamed create_job(), however there is still 
>> no endpoint defined for this method - this is broken
> 
> Right, fixed in CVS now.
> 
> 
>>  #2 submitJob()/create_job(). The described behaviour of this method 
>> has not changed; is this merely a superficial change, or is it intended 
>> to facilitate the separation of Job creation and submission at a later date?
> 
> It is!  job.run ();  triggers the submission.
> 
> The job part is missing a number of description and semantic
> notes.  Also, it is missing exceptions completely - its on
> the TODO list *sigh*
>


OK, I missed the Job.run() method.

> 
>> #3 Regarding the position upon getter/setter methods.
>>
>>    "Many SAGA objects have very frequently use attributes.  To
>>     simplify usage of these objects, setter and getter methods MAY
>>     be defined by the various language bindings, additionally to
>>     the interface described below"
>>
>>   I appreciate this statement. I have been pondering this issue and 
>> believe that getter and setter methods are appropriate for the Java 
>> bindings. In addition to the issue of typesafety they allow the 
>> semantics defined by these attributes to be versioned much more 
>> explicitly. When the SAGA API changes (infrequently ;-) a client using 
>> an unsupported attribute via the getter/setter will receive a compile 
>> time error, otherwise the attribute will be hardcoded as a string and 
>> produce a runtime error. This is less of an issue for dynamic languages 
>> such as Python.
> 
> Agree.
> 
> 
>> #4 Should the close() method be defined as a method of ns_entry? As I 
>> mentioned in an earlier email it is not applicable to Directorys (which 
>> implement ns_entry), and perhaps not to logical_files or 
>> logical_directory. I believe that close() should be defined for classes 
>> as required.
> 
> As said before, I am not sure about this.  Close was
> requested as means of freeing the resource explicitely (i.e.
> timely) on systems with garbage collection (Java ;-).  Maybe
> 'destroy' would have been more appropriate, but that again
> would clash on real files and streams, as 'close' is 'the
> right thing' on those.
> 
> I don't have a better idea right now.  Out?  In?  *shrug*
> 
> 
>>  -3.33 The uniqueness of Context within a Session is a little 
>> ambiguous. Defined as "a single Context instance can get attached only 
>> once to a specific Session instance". Whilst it would be possible to 
>> determine whether the same instance of a Context object has been added 
>> to a session, two different Context instances could describe the same 
>> security information. What is the intention of this restriction? Is 
>> there a better way to specify the uniqueness of Context objects; perhaps 
>> based upon contextType? (see 3.34)
> 
> I pondered about that as well some days ago.  I don't see a
> good reason for that statement anymore.  It simply should
> not matter if a context gets added twice.
> 
> The only potential problem is confusion with remove_context,
> as that should certainly remove only one instance - so a
> double context would be still attached on the session after
> a single remove call.  I don't think that this is a problem
> though.
> 
> I would prefer to delete the statement, if there ar no
> objections...
> 
> 
>>  -3.34 Session.removeContext(Context context) is a little awkward. The 
>> client would have to retrieve the instance Context in order to specify 
>> that it should be removed (see 3.33). Could Context instances within a 
>> Session have labels, removal could then be based upon label?
> 
> We do have cookies for callbacks, so we could also have them
> for contexts, sure.  But then also for tasks (in
> task_container)?  
> 
> I guess its a matter of taste - I can imagine use cases for
> both versions.  But one version is easily mapped to the
> other on in application space.
> 
> 
>> ######### Comments on the Strawman API document
>>
>>  -4.18 Not all methods are documented in revision 0.4, including;
>>         File.read_p()
>>         File.write_p()
>>         File.read_e()
>>         File.write_e()
>> 	File.modes_e()
> 
> Right, thats on the issue list.
> 
> 
>>  -4.19 Buffer arguments should be described as byte arrays, not strings 
>> in File and Ivec.
> 
> Oh, did I miss that?  I though I fixed all the buffer
> strings... - will check.
> 
> Hmm:
> 
>     struct ivec 
>     {
>       long          offeset; // position of data  to be r/w
>       long          length;  // number   of bytes to be r/w
>       array<byte,1> buffer;  // data              to be r/w
>       long          result;  // number   of bytes       r/w
>     }
> 
> Hmm, is byte array in CVS.  I am wondering if we look at the
> version?
> 

Sorry that is an anachronistic comment from revision 0.3 that slipped in.


> 
>>  -4.21 Typo in ivec "offeset" should read "offset"
> 
> Aehm, thanks :-)
> 
> 
>>  -4.22 removeContext "Security Context to add" should read "Security 
>> Context to remove"
> 
> Fixed.
> 
> 
>>  -4.23 removeContext "DoesNotExists" should read "DoesNotExist"
> 
> fixed.
> 
> Thanks, Andre.
> 
> 
>> Andre Merzky wrote:
>>> Hi all, 
>>>
>>> the lates version of the strawman (1.4) is on the wiki.
>>>
>>> Cheers, Andre.
>>>
>>>
> 
> 
>