The thread on the Avalon Component Repository has some merits because it
highlights a couple fundamental problems with the ready supply of shared
components.  There are more than just the ones I am listing here:

* Development in Scratchpad and moving to Components is resource intensive
  and does not encourage quick innovation.

* We should be able to have a repository with components in various stages
  of maturity.

* The Avalon community is just not set up to foster a Component repository,
  and the oversight requirements are beyond the scope of the Avalon PMC as
  it is defined right now.

* Hosting the repository on ASF hardware means we can't support components
  that use GPL or LGPL software.

All of these are legitimate issues.  Throughout the conversation, other
points came to light in regards to the lack of standards for one component
definition, and the fact that some components are not made in a container-
neutral manner.

The solution I propose would allow and foster the creation of several
component repositories, but provide one index so that folks know where to
look for components that they may want to use.  Lets focus on the
infrastructure so that we don't have the issues associated with central
management.  We can leverage the concepts behind existing technologies like
WSDL and the Web Services indexing service.

As long as we know where an indexing service is, we can verify if the component
in question will work for us.  All we need to know is what meta-data is needed
to ensure that the component will work, and what would be an acceptable way to
programmatically access it.

Such an index would have to be easily updatable, and distributable.  For
instance, we can have all the index services able to find each other like
the peer-to-peer networks out there.  The technology exists, and it just
begs to be adapted for something more powerful than downloading the latest
Britney Spears music (yech, I prefer people with real vocal chops).

If we focus our energies down this route, we can help build an infrastructure
that encourages mirroring and distributed component repositories that can
focus on areas of expertise.  Building many smaller communities scales better
than trying to have one all encompassing community because the signal to noise
ratio is much better.

So whadaya think?


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to