Hi all, the lates version of the strawman (1.4) is on the wiki. Cheers, Andre. -- "So much time, so little to do..." -- Garfield
Andre, I have downloaded the latest version of the strawman spec from CVS. There have been a lot of changes, which I expect will clarify many issues. Some immediate _negative_ reaction: #1 The package saga.jobmanagement appears to have changed to saga.resource. This is a big mistake since 'resource' is a far too vague term, anything exposed on the Grid could be considered a resource; including computational resources, file systems, hardware etc. This package name should be specific to the submission and management of computational jobs. #2 The introspection added to the saga.Attribute interface further confuses the issues surrounding vector and "scalar" attributes. There are genuine use cases for vector attributes; for example in the JobDefintion class. However in the strawman the introspection is separated for vector and "scalar" attributes, list_attributes() returns a single unified list of attribute names, and there is no defined behaviour if a vector attribute is requested via get_attribute() or visa versa. This solution is awkward. An alternative solution is to allow any attribute to be returned via get_attribute() and get_vector_attribute(); this is simple since all values are strings, a vector returned by get_attribute() be delimited by comas or parentheses. Then a single has_attribute() methods would be sufficient, and an additional is_vector() method would be useful. #4 It is not clear why the task and task_container interfaces implement the attribute interface. #5 The change from camel case to underscore separated words for packages/classes/methods throughout was an unpleasant shock. This distracts from genuine changes to the API (particularly if like me you use diff to compare the documents). #6 A spell checker should be run on the entire document since typos remain. In a separate email you indicate that you would like to submit this document as a draft for GGF17 by March 31st. What are the implications of this becoming a GGF draft document? I do not expect to be able to comment full on all changes changes in this version by March 31st (including the new monitoring interface), what is the revision process for 'draft' documents. Graeme Andre Merzky wrote:
Hi all,
the lates version of the strawman (1.4) is on the wiki.
Cheers, Andre.
Quoting [Graeme Pound] (Feb 24 2006):
Andre,
I have downloaded the latest version of the strawman spec from CVS. There have been a lot of changes, which I expect will clarify many issues.
Some immediate _negative_ reaction:
#1 The package saga.jobmanagement appears to have changed to saga.resource. This is a big mistake since 'resource' is a far too vague term, anything exposed on the Grid could be considered a resource; including computational resources, file systems, hardware etc. This package name should be specific to the submission and management of computational jobs.
I agree actually, thats was a mistake (mine).
#2 The introspection added to the saga.Attribute interface further confuses the issues surrounding vector and "scalar" attributes. There are genuine use cases for vector attributes; for example in the JobDefintion class.
However in the strawman the introspection is separated for vector and "scalar" attributes, list_attributes() returns a single unified list of attribute names, and there is no defined behaviour if a vector attribute is requested via get_attribute() or visa versa. This solution is awkward.
An alternative solution is to allow any attribute to be returned via get_attribute() and get_vector_attribute(); this is simple since all values are strings, a vector returned by get_attribute() be delimited by comas or parentheses. Then a single has_attribute() methods would be sufficient, and an additional is_vector() method would be useful.
I don't like the dstinction vector/scalar either, it is confusing. If we would not have the (very valid) use cases... ;-) Problem with the approach you propose is that, whatever delimiter you choose, you'll step on somebodies toes. I think space limited is kind of useful, or komma, as the result is at easily human readable... - It might be worth to have both versions: - separate setters/getters for scalar/vector attribs - scalar attrib with vector getter -> list with one element - vector attrib with scalar getter -> space limited string - scalar attrib with vector setter -> set to space limited string - vector attrib with scalar setter -> set to list with one element Well, I say space limited - but see above, no good idea. is_vector sounds indeed useful, simplifies the inspection.
#4 It is not clear why the task and task_container interfaces implement the attribute interface.
Ouch! Thanks, they should not!
#5 The change from camel case to underscore separated words for packages/classes/methods throughout was an unpleasant shock. This distracts from genuine changes to the API (particularly if like me you use diff to compare the documents).
The problem was that the naming was different in different packages, I tried to make it consistent. I understand that diff is a problem: however, I also changed a lot of formatting, so a diff is problematic in general I'm afraid. I hope both, formatting and naming, are stabe now.
#6 A spell checker should be run on the entire document since typos remain.
Oh yes. Oooooh yes - I am notoriously bad in spelling I'm afraid...
In a separate email you indicate that you would like to submit this document as a draft for GGF17 by March 31st. What are the implications of this becoming a GGF draft document?
That has no real implications apart from making a statement: 'its getting stable, and will soon be submitted to public review'. We have a milestone in the WG charter to do that as of next GGF.
I do not expect to be able to comment full on all changes changes in this version by March 31st (including the new monitoring interface), what is the revision process for 'draft' documents.
The revision process stays as it is, on the list and informal. Only as the document gets submitted to public review, i.e. enters the GGF standardization process, the feedback loop changes somewhat: it goes to a wider public (GFSG has to review it, other WGs get notified), and responses from that period MUST be addressed before the document can advance in the process, i.e. get 'draft recommendation' status. Cheers, Andre.
Graeme
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
Andre,
#2 The introspection added to the saga.Attribute interface further confuses the issues surrounding vector and "scalar" attributes. There are genuine use cases for vector attributes; for example in the JobDefintion class.
However in the strawman the introspection is separated for vector and "scalar" attributes, list_attributes() returns a single unified list of attribute names, and there is no defined behaviour if a vector attribute is requested via get_attribute() or visa versa. This solution is awkward.
An alternative solution is to allow any attribute to be returned via get_attribute() and get_vector_attribute(); this is simple since all values are strings, a vector returned by get_attribute() be delimited by comas or parentheses. Then a single has_attribute() methods would be sufficient, and an additional is_vector() method would be useful.
I don't like the dstinction vector/scalar either, it is confusing. If we would not have the (very valid) use cases... ;-)
Problem with the approach you propose is that, whatever delimiter you choose, you'll step on somebodies toes. I think space limited is kind of useful, or komma, as the result is at easily human readable... -
It might be worth to have both versions:
- separate setters/getters for scalar/vector attribs - scalar attrib with vector getter -> list with one element - vector attrib with scalar getter -> space limited string - scalar attrib with vector setter -> set to space limited string - vector attrib with scalar setter -> set to list with one element Well, I say space limited - but see above, no good idea.
is_vector sounds indeed useful, simplifies the inspection.
The behaviour of the equals() method is also ill-defined when called against a vector attribute. The problem would go away if a delimiter is defined by the strawman for a string representation of vector attributes. Graeme
Right, I fixed that now. BTW, order of vector elements should be of no impact I guess (would make equals awkward to use...) Andre. Quoting [Graeme Pound] (Mar 01 2006):
Date: Wed, 01 Mar 2006 12:34:21 +0000 From: Graeme Pound <G.E.POUND@soton.ac.uk> To: Andre Merzky <andre@merzky.net> CC: SAGA RG <saga-rg@ggf.org> Subject: Re: [saga-rg] 1.4 version of the spec
Andre,
#2 The introspection added to the saga.Attribute interface further confuses the issues surrounding vector and "scalar" attributes. There are genuine use cases for vector attributes; for example in the JobDefintion class.
However in the strawman the introspection is separated for vector and "scalar" attributes, list_attributes() returns a single unified list of attribute names, and there is no defined behaviour if a vector attribute is requested via get_attribute() or visa versa. This solution is awkward.
An alternative solution is to allow any attribute to be returned via get_attribute() and get_vector_attribute(); this is simple since all values are strings, a vector returned by get_attribute() be delimited by comas or parentheses. Then a single has_attribute() methods would be sufficient, and an additional is_vector() method would be useful.
I don't like the dstinction vector/scalar either, it is confusing. If we would not have the (very valid) use cases... ;-)
Problem with the approach you propose is that, whatever delimiter you choose, you'll step on somebodies toes. I think space limited is kind of useful, or komma, as the result is at easily human readable... -
It might be worth to have both versions:
- separate setters/getters for scalar/vector attribs - scalar attrib with vector getter -> list with one element - vector attrib with scalar getter -> space limited string - scalar attrib with vector setter -> set to space limited string - vector attrib with scalar setter -> set to list with one element Well, I say space limited - but see above, no good idea.
is_vector sounds indeed useful, simplifies the inspection.
The behaviour of the equals() method is also ill-defined when called against a vector attribute. The problem would go away if a delimiter is defined by the strawman for a string representation of vector attributes.
Graeme
-- "So much time, so little to do..." -- Garfield
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.
participants (2)
-
Andre Merzky -
Graeme Pound