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