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

[Andre Merzky]

Oops! thanks :-)

A.

Quoting [Graeme Pound] (Feb 24 2006):
> Date: Fri, 24 Feb 2006 11:48:20 +0000
> From: Graeme Pound <G.E.POUND at soton.ac.uk>
> To: Andre Merzky <andre at merzky.net>, SAGA RG <saga-rg at ggf.org>
> Subject: Re: [saga-rg] 1.4 version of the spec [part2]
> 
> 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.
> >>>
> >>>
> >
> >
> >



-- 
"So much time, so little to do..."  -- Garfield