Oops! thanks :-) A. Quoting [Graeme Pound] (Feb 24 2006):
Date: Fri, 24 Feb 2006 11:48:20 +0000 From: Graeme Pound <G.E.POUND@soton.ac.uk> To: Andre Merzky <andre@merzky.net>, SAGA RG <saga-rg@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