Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Message-ID: <3FAAE721.4030509@apache.org>
Date: Fri, 07 Nov 2003 01:28:17 +0100
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Avalon Developers List <dev@avalon.apache.org>
Subject: Re: [PROPOSAL] An Avalon Component Repository
References: <bobqdg$gts$1@sea.gmane.org> <3FA9A09E.7020407@apache.org>
 <bodsdv$c7n$1@sea.gmane.org>
In-Reply-To: <bodsdv$c7n$1@sea.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Leo Simons wrote:

> Stephen McConnell wrote:
>
>>> 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)? 


Simply because your branding the repository as an Avalon repository.  
What does that mean? What is means is a bunch of components that have 
computational dependencies on avalon apis and implementations together 
with grand claims of support.  In reality its just plain missleading.  
This isn't so much a thing about a single component contract - its much 
more about understanding the differences in the component contract 
interpritations.  Keep in mind that those differences are sufficient to 
break the component contract.  Take for example the recent post 
concerning using a parent container service manager in Fortress - what 
relalevance has this to the Avalon component contract - absolutely 
none!  Any yet that guy is going to go ahead an invest his time in 
coding something up that is specific to Fortress.  That's a 
dissapointment - why - because you talking about a common repository for 
wanabe-components and you want to align it with Avalon. 

As to the timeframe - months or years?  That is in part a function of 
the market, this community, and key individuals. Getting down and dirty 
is part of the process - do we (Avalon) consider ECM semantics as part 
of the core framework?  I don't because the specification just isn't 
sufficient.  Are phoenix semantics part of the core framework - yes - 
but depricated relative to a common set of context entries.  Are 
Fortress semantics (which are largely related to ECM semantics) part of 
the framework - no - simply because we have not identified and 
documented the semantics distinctions and implications of those 
distinctions.

The fast track to a single component contract is:

* elimination of selectors
* elimination of pooled and per-thread lifestyle strategies
* elimination of framework marker interfaces

Validation of any component against this senario and you have the 
context for establishing a component repository of value.

>
>>> So why *should there not be an avalon-hosted component repository*?
>>>
>>> 1) Oversight.
>>
>> Agreed.
>>
>>>
>>> 2) Brand dellution.
>>
>> Agreed.
>>
>>> 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


Nope.
We have lots of scope for expansion.  Last months was 614 messages and 
there have more than a few months where Avalon trafic has been up and 
over 1000 per month.  Container-related is not the issue -- but it is 
perhaps a stimulus in terms of what is and is not an Avalon component.

>
>
>>> 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. 


No.

The barrier is the policy and procedures that are put in place.
I've mentioned before (on the PMC list) that I would like to see a soft 
zone here in Avalon supporting and facililitating component development 
and experimentation.  Unfortunately I have not managed to get the value 
of that across - but I'm still keen to see this happening - becuase here 
is where the skills are - and here is where *we* can be constructive in 
terms of other people learning about this stuff.

>
>
>>> 6) Scope.
>>
>>
>> Thats' a loaded argument.
>
>
> I'd hope it wouldn't be. Let's try and be open. 


Being open - as far as I am concerned the notion of an SF base is not an 
option.  The question is "do we setup an Apache repository or not".  If 
its here at Apache - count me in.


>> I agree with several of your points - and in particular aspects 
>> concerning focus.
>
>
> This just reeks of potential for agreement :D 


You know me - I'm a reasonable guy!!

>
>> 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.


I agree.  I'm thinking right now about the FTP project and how something 
like that needs an Avalon Component Repository.  But lets be up-front - 
if the FTP project came in as a component I would getting in there and 
bringing it into conformance - and doing this in the context of a 
policies that ensured that I could do this if needed.  And if 
conformance was not possible - then those same policies would let me 
kick-it-out.  But to that I need a conformance criteria before I need a 
playground.

>
>>> 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. 


However, Avalon continuues to grow and develop.  Out components in 
cornerstone have taken a big jump forward in quality.  Or web site is 
better than it has ever been.  Our focus and activities have never been 
as united as it is today.  We still have more to do with respect to 
Excalibur - but the bottom line is core community and the core product 
line is better today then it has been in the history of Avalon. I agree 
that this does not deliver a concrete solution to developers of new 
components - but it does raise a relevant subject - "what is the role of 
the PMC and the community relative to facilitating new component iniatives"?

My own opinion is that we need a new CVS repository - avalon-playground.

What's the difference between avalon-playground and avalon-sandbox - 
simple - things in playground are not destined for Avalon - its simply 
an infrastructure to support and enable people who want to do new 
things.  What is the exit criteria for playground content?  Its the 
development of the individuals who come to play.

I.e. Avalonia - the center for component developer development.

>
>> 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


Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org