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

Fri Feb 3 04:37:00 CST 2006

Well, I can't make up my own mind on how to react on the
GFSG discussion.  Well, please allow me to post two reponses
:-)

-----------------------------------------------------------
Version one:

  Well, I am quite furious to be honest.  Why the heck did
  we sit down in Boston to discuss the SAGA scope with both
  GFSG members and OGSA/WSRF folx?  We came to a conclusion
  there: SAGA scope is ok for now, they SHOULD be WG, go
  ahead.  The issue was _settled_.  Once more, since the
  issue has been settled about five times by now, since the
  formation of the group at GGF10 (just a reminder: ~50
  votes for WG, 2 votes for RG).

  So, here we are, 3 years later, and are STILL discussing
  the same issue over and over again, and all promises that
  the issue is closed are forgotten again.  What a waste of
  time... :-(

  The goal of the members of the SAGA group is AFAICS to
  define and standardize a well scoped, very simple, and
  highly needed API.  Just that.

  If there is a perceived need of the GFSG that GGF needs a
  public API facade, or of the OGSA folx that there is a
  need for a simple API on top of OGSA, then they probably
  should form a RG and define that!

  I think its not the task of the GFSG to say: "you do good
  work, but please do something different."  GGF does not
  work on requests, but is community driven.  If other
  people would be interested in widening the scope of the
  SAGA-RG, they would show up in the meetings, submit use
  cases, author documents.  Be active (hello OGSA?).

  Those people who DO show up in our meetings (RPC, CPR,
  DRMAA, ByteIO, BES etc.) are satisfied with our scope
  (mostly we say: nice for you to come, but we have limited
  scope right now, your part comes later).

  There are more than a few people scared away by the fact
  that SAGA is a research group, and still after three
  years, did not manage to become a WG, as was the plan in
  the first place!

  Well, I think you got the point: in my opinion the
  decision to block the long priomsed flip into a WG is
  against the agreement we had with the GFSG, and not
  acceptable.

------------------------------------------------------------

------------------------------------------------------------
Version two:

  Thinking positively, that is really good news.  Well, what
  GFSG really says is: "Guys, you do a great job, we need
  more of this".  Having the SAGA group scope broadening as
  an umbrella for community driven Grid APIs seems like a
  very good thing to do.

  Several practical points come to my mind, though:

   - we certainly don't want to delay the release of the
     current SAGA documents, in particular of the API spec,
     as the SAGA API is sorely needed NOW.

   - The current API draft covers both functional (scope)
     and non functional (look and feel etc) aspwcts of the
     SAGA API.  That defeats the approach proposed by the
     GFSG.  However, I think that splitting the document NOW
     is not the way to solve this (we decided against that
     at last GGF).  

     Instead I would propose to continue our current work,
     with the declared goal to have the SAGA-API v.1
     finalized ASAP, and then go ahead and start with a
     look-and-feel document afresh, based on our experience
     with the API.  Alterantively, and given enough interest
     (see point below), both pathes can be performed in
     parallel.

   - well, in order to do what the GFSG proposes we need
     more active people.  And active meaning really active.
     It seems not enough to chat with other groups now and
     then: we need active participation of their group
     members in the SAGA document and API work.  

     It is not obvious to me how to achieve that, and if
     that need for active participation is perceived outside
     our group and the GFSG.

  So I think the buttom line is: the way proposed by the
  GFSG offers a number of opportunities.  

  However, if we want to keep the deadlines attached to our
  current work, we would need to spawn a dedicated WG for
  these docs immediately (i.e.  as of GGF16!) (possibly:
  iSAGA-WG - initial SAGA ;-P) That would basically move the
  current group to iSAGA-WG, with the scope defined by the
  current API spec.

------------------------------------------------------------

Hmm, the second version is probably the better one.  Anyway,
I am _really_ angry that promises by the GFSG are not kept.

Cheers, Andre.

Quoting [Andre Merzky] (Jan 24 2006):
> Date: Tue, 24 Jan 2006 19:13:23 +0100
> From: Andre Merzky <andre at merzky.net>
> To: Simple API for Grid Applications WG <saga-rg at ggf.org>
> Subject: Fwd (s.newhouse at omii.ac.uk): Re: SAGA - WG?
> 
> Dear group, 
> 
> as you know, we are currently in transition from a GGF
> Research Group to a GGF Working Group, which will enable 
> us to submit documents into the standardization track.  
> The last action from our side was to submit the proposed 
> WG charter to our Area Directors (Steven and Dieter), and
> wait for the last step in the process, the GFSG approval of
> that charter.
> 
> Below you find the answer we got from the GFSG.  I know
> people will have strong opinions about that, both positive
> and negative (well, certainly I do anyway :-P ), so we would
> like to discuss the GFSG answer on this list.  It would be
> favourable to come to a group internal conclusion, and a
> solid opinion, about the groups future before GGF16 - that
> means within the next two weeks.
> 
> Best regards, 
> 
>   your friendly group chairs ;-)
> 
> 
> 
> ----- Forwarded message from Steven Newhouse <s.newhouse at omii.ac.uk> -----
> 
> > Date: Mon, 23 Jan 2006 07:38:45 +0000
> > From: Steven Newhouse <s.newhouse at omii.ac.uk>
> > To: Andre Merzky <andre at merzky.net>, Shantenu Jha <s.jha at ucl.ac.uk>,
> > 	Tom Goodale <goodale at cct.lsu.edu>
> > CC: Dieter Kranzlmueller <dk at gup.jku.at>
> > Subject: Re: SAGA - WG?
> > 
> > Dear Andre, Shantenu & Tom,
> > 
> > At the GFSG meeting last week, there was a general discussion as to how
> > GFSG should/could steer the standards areas to increase the impact of
> > GGF. One of the discussions related to the Applications area and how we
> > (as Area Directors) could help to structure the activity to align work 
> > with activities in the Architecture (i.e. OGSA) area.
> > 
> > There was considerable interest from the rest of the GFSG in the SAGA 
> > activities and the potential uptake that the generation of stable
> > client-side interfaces (and potentially command line tools that build on
> > these interfaces) could provide. The GFSG saw SAGA-RG as an important 
> > step forward for grids being adopted by the wider community.
> > 
> > That's the good news!
> > 
> > We mentioned the pending SAGA-WG charter and that this was the next step 
> > to move things forward. 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.
> > 
> > One proposed solution to this is that SAGA-RG stays as it is. It is
> > doing very valuable work collecting use cases, developing the strawman
> > API that supports these use cases and discussing implementation issues
> > through real experience. However, clearly there are elements within the 
> > strawman that are ready to move to the next level.
> > 
> > It is proposed that these aspects should be developed as standalone WG's
> > starting with a common look and feel, and then picking up on (say) jobs 
> > & file movement to drive some domain specific applications of the common 
> > look and feel. The result would be an umbrella-RG (SAGA) with a set of 
> > coupled WGs for the different aspects.
> > 
> > So there are two ways forward - you have _our_ support which ever way 
> > _you_ choose to go forward.
> > 
> > If you go forward with then the current charter then you will need to be 
> > explicit as to which areas you will be doing (to allow space for other 
> > WG's to come forward), i.e. you need to define your API scope. Elements 
> > of the API will change at different rates and putting this all into one 
> > specification adds to its complexity. Small tightly focussed 
> > specifications have had much greater success within GGF. This may be 
> > something else to consider.
> > 
> > As a conclusion we hope that you will think about this great opportunity 
> > to take the responsibility for the bigger picture, and that you will 
> > adapt your plans accordingly from this feedback. We would certainly be 
> > available to support you in this quest. At the same time, it has also 
> > been agreed to continue the regular bit-flipping procedure with your 
> > charter, should you insist on your currently proposed approach.
> > 
> > Steven & Dieter
-- 
+-----------------------------------------------------------------+
| Andre Merzky                      | phon: +31 - 20 - 598 - 7759 |
| Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 |
| Dept. of Computer Science         | mail: merzky at cs.vu.nl       |
| De Boelelaan 1083a                | www:  http://www.merzky.net |
| 1081 HV Amsterdam, Netherlands    |                             |
+-----------------------------------------------------------------+