[saga-rg] 1.4 version of the spec

[Andre Merzky]

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