[saga-rg] BOUNCE saga-rg at ggf.org: Non-member submission from ["Rosa M. Badia" <rosab at ac.upc.edu>] (fwd)

[Andre Merzky]

We brought that perspective up in earlier discussions with
the GFSG as well.  In fact, we have been told by IBM
representatives the very same thing: no active participation
because its not a WG.

Andre.


Quoting [Shantenu Jha] (Jan 25 2006):
> Date: Wed, 25 Jan 2006 17:35:10 +0000 (GMT)
> From: Shantenu Jha <s.jha at ucl.ac.uk>
> To: saga-rg at ggf.org
> Cc: rosab at ac.upc.edu
> Subject: [saga-rg] BOUNCE saga-rg at ggf.org:    Non-member submission from ["Rosa M.
>  Badia" <rosab at ac.upc.edu>] (fwd)
> 
> Bounced message from Rosa below. Interesting perspective. 
> 
> Shantenu 
> 
> PS: My own $0.02 coming soon....
> 
> 
> Date: Wed, 25 Jan 2006 18:23:11 +0100
> From: "Rosa M. Badia" <rosab at ac.upc.edu>
> To: Craig Lee <craig at rushg.aero.org>
> Cc: Simple API for Grid Applications WG <saga-rg at ggf.org>
> Subject: Re: [saga-rg] Fwd (s.newhouse at omii.ac.uk): Re: SAGA - WG?
> 
> Last November I acted as reviewer in a project, and they stated that they
> have not taken into account SAGA because it is a RG and there was very few
> (or no?) industry involved. They also claimed that as RG the results were
> coming to slowly.
> 
> Becoming a WG can of course attract users from projects and industry, I 
> do not know if it will attract more effort at the implementation level too.
> 
> Just to give a use-case :-)
> 
> Best regards,
> 
> Rosa
> 
> 
> 
> Craig Lee wrote:
> 
> >
> > All,
> >
> > First of all, allow me to say that this is a good problem to have.
> > The fact that the GFSG is considering whether SAGA should
> > be one WG or an umbrella RG for multiple WGs means that
> > people view it as important.
> >
> > My personal opinion is that the SAGA-RG could continue as
> > this umbrella organization, but to follow through with the
> > original SAGA intent, an initial WG should be formed that is
> > focused on _S_AGA.  To emphasize the _simple_ in
> > SAGA I keep coming back to the analogy of "the six calls
> > in MPI".  Whether the current SAGA API is simple enough
> > is separate discussion.  In any case, the API should be
> > (a) minimally complete, (b) easy for implementers to implement
> > and (c) easy for new grid users to use.
> >
> > As long as the umbrella SAGA-RG persists, it can consider
> > issues of enhancing the API in various functional areas,
> > e.g., data movement, and also establishing a common
> > look-and-feel across them all.  WGs could be spun-off
> > as necessary.
> >
> > Just my 2 cents.
> >
> > --Craig
> >
> > At 10:13 AM 1/24/2006, Andre Merzky wrote:
> >
> >> 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    |                             |
> >> +-----------------------------------------------------------------+
-- 
+-----------------------------------------------------------------+
| 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    |                             |
+-----------------------------------------------------------------+