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.