On Thu, 1 Mar 2001, Peter Donald wrote:
> Hi,
>
> Not to be a stick in the mud but ...
S'Ok, I'll be a stick in the mud too... :)
> what this sounds like is Avalon ;) It
> is true that most discussion on Avalon is concerned about the
> pattern/framework (or more specifically the kernel aspect of the previous).
> However what is proposed is still overlapping with Avalon stated purpose
> (ie place where server components for Apache are located). Damn I feel like
> a broken record here.
>
> Perhaps it is better to analyze the infrastructure rather than the content.
> Many seem to want a CJAN distribution system for use both internally and
> externally to apache. CJAN would serve as a distribution point for
> products. Add a directory on top of CJAN and you have a catalog.
> Standardize the layout/structure/testing/gumpiness/whatever of each product
> and your a few more steps in the right direction. So I see
> Catalog/CJAN/Gump as one infrastructure point - lets call this Scaffold for
> discussion.
This is what I identified as the Catalog Service/Dewey in a recent email (
just so I can match up the ideas with each of the names we are using )
>
> Another point identified is the need for a scratch pad CVS for giving birth
> to new components.
>
> Another point is shared CVS access - lets call this the Commons.
>
These two are what we have discussed as the Agora Service ( aka sandbox
and whatnot ) and they are pretty much rolled in together. The scratch pad
is facilitated by shared CVS access, and the development of tools is
facilitated by both so...
The 'Commons' is the word I proposed to denote the project as a whole, a
collection of services that facilitate re-use and shared components/code
between projects.
> So we have the Scaffold, the ScratchPad and the Commons. All of these are
> infrastructure points rather than content.
I absolutely agree if you switch /content/products/ and swap some names
around ;). Essentially the Commons Project is an infrastructure of support
services for jakarta ( my vision at least... YVMV ). Having it as a
seperate project helps us develop the methods and processes to do this in
a way that doesn't intrude upon the internal development of the jakarta
projects. As the project develops and services mature, projects can start
using them for what they are without disturbing what exists within that
project.
> Leaving aside Commons for the
> moment, the other two should be integrated into all projects IMHO. Some
> projects allow ScratchPad work to occur in main CVS tree, others use
> branches, whiteboard directories, proposal directories and contrib
> directories. The Scaffold would benefit all jakarta projects.
>
I agree and disagree at the same time. If by integrate you mean 'can be
used by all projects as they see fit' I agree. If you mean 'will each
implement in their own way' I disagree. Part of what I think this project
provides is some of the support services/infrastructure to do these things
without forcing each project to do them on their own ( reuse on a human
resources scale if you want to look at it that way). In a way it is a
place for myself and people who want to contribute *something* but lack
the expertise to build a framework product to contribute to the jakarta
project in a way that benefits all of the project. To push the library
image a bit too far... I don't mind being the person that fills the card
catalog and puts the books back on the shelves if the project on the
whole needs that work done and it will free up the people who *don't*
want to have to do that on but end up doing them anyways out of necessity.
> The Commons is something I would like to see aswell but there does not seem
> to be a lot of support for it aside from Sam at the momment ;)
>
> So now onto content.
>
> Does this project overlap with Avalons stated purpose? Largely it is
> identical. Provide a place to share server-side components between Apache
> projects. You could complain that Avalon is too integrated or too
> frameworky then there is a perfect place to start fixing it ;) My concern
> is that with two projects with identical purposes is going to cause a
> little confusion. Worse yet I have a feeling that it may be possible that
> the same issues/mistakes/problems that occur within Avalon will occur
> within this project. I think Sam referred to Avalon as the eternal alpha
> project (IIRC it has been around for about 3 years and is only starting to
> stabilize recently).
Here is my take on this: Avalon is a pre-existing project that has
something of a mixed/varying purpose. From the outside the project appears
to be a framework/kernel/system of developing server software in java.
>From what you say on this list and the general list, it is a set of
reusable components. It sounds as though the purpose/mission of Avalon is
somewhat bendable at this time, and I would really hesitate to drop yet
another set of goals and visions on that group from the outside. I would
take this from the other direction and say 'you now have a chance to
focus Avalon on the core product it is already known for *and* you can
keep your userbase without confusing people with a repurposing of Avalon
*and* everyone in Avalon is welcome here, it sounds like there are some
good candidates for really good single use components'
>
> Speaking for myself (and not for Avalon group) I would love to see a
> flattening of CVS access and allow an area to develope and maintain these
> different components within Avalon. I don't care about the politics of each
> component - as long as they are labeled as STABLE/ALPHA/BETA/whatever and
> stick to it.
The flattening of the CVS access I can't really comment on, I haven't been
here long enough to guess what effect that will have on the process. The
versioning/labeling I absolutely agree with.
>
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
>
