[saga-rg] 1.4 version of the spec [part 2]

[Graeme Pound]

Andre,

Further comments on revision 0.4 (not all negative ;-)

Thanks
    Graeme


  #1 submitJob() has been renamed create_job(), however there is still
no endpoint defined for this method - this is broken

  #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?

#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.

#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.


  -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)

  -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?


######### 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()

  -4.19 Buffer arguments should be described as byte arrays, not strings
in File and Ivec.

  -4.21 Typo in ivec "offeset" should read "offset"

  -4.22 removeContext "Security Context to add" should read "Security
Context to remove"

  -4.23 removeContext "DoesNotExists" should read "DoesNotExist"



Andre Merzky wrote:
 > Hi all,
 >
 > the lates version of the strawman (1.4) is on the wiki.
 >
 > Cheers, Andre.
 >
 >




Andre Merzky wrote:
> Hi all, 
> 
> the lates version of the strawman (1.4) is on the wiki.
> 
> Cheers, Andre.
> 
>