[saga-rg] Fwd (s.newhouse at omii.ac.uk): Re: SAGA - WG?

[Steven Newhouse]

I'll try and provide factual responses rather than opinions! BUt I 
expect I'll fail.

>   -- If the lack of focus is a concern (as has been expressed on this
>   list and privately by some parts of the community), can that not be
>   effectively addressed without spawning?

The current WG charter does not scope what it would explicitly do. If 
another group came along to do an API for X, the SAGA-WG _could_ say 
they it was within their scope. This is simple to fix by...

Explicitly, scoping the proposed SAGA-WG activities would produce a 
list. A long list or a short list is in the eye of the beholder. But a 
question that would have to be answered why is this list of activities 
(API area) all part of one WG?

The reason from SAGA is that there needs to be co-ordination - which I 
think there is general agreement about there is a need for this. The 
question IMHO is how to deliver this co-ordination. This appears to be 
the issue.

>   Also, spawning groups in itself isn't a guarantee of focus or
>   simplicity. Spawning groups has a resultant high risk possibility
>   that the spawned subgroups make each subsystem too exhaustive. Not
>   that it can't happen with a single group, but just that the
>   temptation is less acute. Similarly, might not each sub-group still
>   end up losing focus (with the added overhead that fragmentation
>   involves)?

A WG has a specific set of explicit deliverables/milestones that reigns 
it in. WG creep is monitored and controlled by the AD's and the GFSG.

>  -- In addition to concerns about the exact working relationship
>   issues, a MAJOR fear that I have is that spawning groups might just
>   be a symmetry-breaking event, i.e., where the common look-and-feel
>   might be lost forever and will be irrecoverable in spite of an
>   umbrella SAGA-RG.

Each WG has a remit to produce something. The 'umbrella' group looks at 
taking the output from the WG and ingesting it to ensure that it 
'works'. The umbrella group has a lobbying obligation on the WG to make 
sure it fits. If the WG activity is well defined (informed form the RG 
activity) this should not be an issue.

>   SAGA is a meant to be a single consistent API. Might help to go back
>   to the the MPI analogy. Did different parts of the MPI specification
>   process evolve under distinct working groups? Or did the different
>   'sub-systems' evolve together? Why?

MPI (AFAIK) was put together by sub-groups (point 2 point, collective, 
etc.) working in isolation and then syncing up to be consistent.

>  -- EXACT working relationship between umbrella SAGA-RG and spawned
>     SAGA-WGs?

For OGSA the spawned WGs are asked to join the OGSA telecons & the F2F 
to report on progress. There is a two way communication. A WG given an 
OGSA prefix has a 'responsibility' to engage in this. It should be (is) 
in their charter to do so... I believe.

>  -- Assuming SAGA goes with the spawning approach: What are the
>   necessary conditions to spawn future groups? e.g., must each
>   subsystem get its own WG?  What are the sufficient conditions?

If its an identifiable scoped bit of work it should IMHO be in a WG.

>  -- At the risk of opening a whole new can-of-worms and that too a
>   rather polemical one: Is the Go-henceforth-and-spawn suggestion a
>   proxy to align SAGA more intimately with OGSA?

On a one-to-one level... no in my view. Its a model. The SAGA job 
submission activity might use the OGSA-BES and ByteIO services as part 
of one implementation, or WS-GRAM and RFT as part of another implementation.

>   What does, "SAGA being the public-face of OGSA" mean and imply?

SAGA being the higher-level API that an application developer might use 
to access service infrastructure, ONE implementation of that API would 
use the OGSA-* services.

>   Whereas I'm all for the alignment of SAGA and OGSA (even more if as
>   has been said, "SAGA is the application area flagship of the GGF"),
>   is there a premature and/or even an over emphasis on "aligning" SAGA and 
>   OGSA?  If so, is this in the best interest of OGSA? SAGA?  or GGF as a
>   whole?

Alignment - OK. Tied exclusively too - not OK.

>  -- "Some concern was expressed about focus and broad
>   scope. Especially as other domains would like to bring forward their
>   own domains (data access, data movement, etc) for client side API
>   standardisation."
> 
>   I'm sure there is more to it than the following, but as a simpler
>   first step, why can't we have more sanity checks with such domains
>   e.g.,
>   http://www-unix.gridforum.org/mail_archive/saga-rg/2005/10/msg00017.html
>   Doesn't approach appears to be working for DRMAA, GridRPC and
>   GridCPR, if not data movement?

The RG spawning WG model would IMHO do that. These are all tightly 
scoped WGs.

>   -- In the case of a split opinion, how does the group make the final
>   call?

AFAIK... the final call MUST go to the list. Rough consensus is the 
phrase... what that means in practice... has to be seen.

Steven
-- 
----------------------------------------------------------------
Dr Steven Newhouse                        Tel:+44 (0)2380 598789
Director, Open Middleware Infrastructure Institute-UK (OMII-UK)
c/o Suite 6005, Faraday Building (B21), Highfield Campus,
Southampton University, Highfield, Southampton, SO17 1BJ,  UK