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

[Shantenu Jha]

>It would be favourable to come to a group internal conclusion, and a
>solid opinion, about the groups future before GGF16

As of yet I don't think the implications (and/or operational details) of
the various options have been explored sufficiently -- and definitely not
PUBLICLY, as discussions have been confined to an overlap between GFSG and
SAGA chairs. A quick look at the mailing list will indicate that there was
no real follow up discussion on SAGA's roadmap from the notes that Craig,
Andre and I posted from the bit-flipping meeting at GGF-Boston.

Consequently, I think this thread as of now should be less about stating a
preference upfront but an attempt to explore the implications before
making a collective decision. 

(For the records, as we revisit the issue in the run-up to GGF-Athens, at
this stage I'm open to either option, but will hopefully feel strongly
about one or the other by Athens.)

There are at least three distinct issues that are being masked by the
question of to-spawn-or-not-to-spawn. They are, i) SAGA's focus and scope
(as opposed to simplicity), ii) SAGA's alignment with GGF's flagship OGSA
and iii) the quickest way to generate a stable, implementable and
minimally complete API.
 
Here is a rushed attempt to collate some of the issues that I feel
either need clarification, say from GFSG members and/or just need
further discussion.

  -- 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? Is it really a lack of focus
  or is it insufficient scope documentation that has lead to a
  perceived lack of focus?

  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)?

 -- 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.

  There is the risk of easy decomposition into focussed parts, but
  then not being able to put the pieces coherently back together
  again.

  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?

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

  Tom raised this yesterday too and I think this is a critical point.

  Can someone with insight into the workings of the OGSA group explain
  the level of coupling between the umbrella OGSA group and the
  smaller subgroups? What influence does umbrella OGSA have on OGSA
  subgroups?  How does the umbrella group coordinate the subgroups,
  given the different levels of complexity and rates of progress?

 -- 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?

 -- 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?

  What does, "SAGA being the public-face of OGSA" mean and imply?
  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?

  As some may remember in the modified charter, we propose to write an
  Informational Document -- "SAGA compatability with GGF middleware"
  which will, ".. survey the compatability of SAGA reference
  implementations with underlying models of grid-middleware including,
  but not confined to OGSA."

  Q: Although it would be one heck of a job, would it help (for either
  way forward) if we brought the timescale for producing this document
  forward, to say around GGF17 (September)?

  [It has been said before that, " the SAGA reference implementations
  need checks against OGSA compliant implementations as those become
  available".  I think it is premature to have the above, but keeping
  this in mind we are having an implementation discussion at
  GGF-Athens.]

 -- "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?

  -- In the case of a split opinion, how does the group make the final
  call?  As mentioned on this thread yesterday, there are strong
  opinions for and against the spawning. Thus it might just be timely
  to ask: As per GGF by-laws what constitutes a final and binding
  decision for the group? A show of hands at a GGF? E-mail ayes/nays? 
  Or is it undemocratic and determined by group-chairs? Or is it
  totalitarian and imposable by the GFSG? ;-)


Just my $0.02...
Shantenu