The rationale behind a common component repository is obvious: there are lots of (open source) avalon(-compatible) components out there, and a single place for hosting/finding all of those means less infrastructure overhead, less googling, in other words, we get all the benefits of one-stop-shopping. It also means that a single community can be built around multiple components (much like jakarta commons) that would otherwise likely be single-man projects.
I'm not convinced. Before such a vision is realistic we need to have a *single* avalon component contract.
why? There is a need for sharing. Why should we wait until we have a single component contract (which is imnsho quite a few months if not years from being 'fully' realized)?
So why *should there not be an avalon-hosted component repository*?Agreed.
1) Oversight.Agreed.
2) Brand dellution.
3) KISS.Agreed.
4) Size.Disagree - well at least I think your exagerating. If we look at the level of component related traffic - well - its small - really small.
which might just be because all the available traffic space is taken up by container-related traffic :D
5) Barrier to entry.
Depends on your defintion of a component repository.
sure does! Lets define it as vaguely as "something maintained using CVS" and there's your barrier.
6) Scope.
Thats' a loaded argument.
I'd hope it wouldn't be. Let's try and be open.
I agree with several of your points - and in particular aspects concerning focus.
This just reeks of potential for agreement :D
But I don't agree with the conclusions. Instead I think we should be going beyond the question of "where is the repository" and instead enable repositories using Avalon tools and technologies that facilitate better conformance, easier discovery, and automation of usage.
that should happen too. I think there can be a positive spiral between the development of such technology, and the existence of open source material actually using it.
The Obvious Alternative
-----------------------
There should be a *seperate project* for hosting avalon components.
Another obviouse conclusion - "there sould be a seperate directory facilitating component discovery based on Avalon component management technology".
yep.
Another proposal
----------------
No need for another shakeup. Instead, we continue the stready improvement and development of the Avalon content, migrating stuff to commons when appropriate, improving quality of existing components when appropriate, keeping links to other activities active and alive.
That is an approach which has consistently failed to work over the last few years. Over the past few months, I've seen about 3 dozen posts in this community about the addition of cool new components to the avalon codebase, but what happens is that people run out of steam developing their component on their own, never bother to submit a website patch, and lots of reuse potential is lost.
And at the same time - build the tools supporting component and service management that facilite component based development and enable automated component validation, discovery, deployment, execution and management.
+1.
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
