[RRT] Getting back to the basics (long)

[Berin Loritsch <bl...@apache.org>]

RRT = Radical Random Thought

Let's get back to the basics, and answer some fundamental questions.  First,
what is the goal of the Avalon team?  Second, how do current Avalon technologies
fit in to this vision?

For me, the goal of the Avalon team is to produce a kick-A container and show
just how elegant and simple component based programming can be.  This is a very
general statement on purpose, but in the end I think it is what we all want deep
down inside.

As to the current Avalon technologies, they provide a foundation, and a set of
building blocks and features that show the power of components.  Before we get
into the nitty gritty details, let's review some basic foundational principles.

Components
----------

Components are reusable pieces that are managed by containers.  They are the
building blocks of applications.

Containers
----------

Containers are the central nervous system of COP.  They create components and
manage their instances.  They map a component implementation to a request for
a component type.  They also have the ability to apply new features to existing
components.

IOC
---

The core pattern used to manage components.  IOC provides the mechanisms to
isolate components from each other as much as possible, yet still provide
functional and robust components.

SOC
---

The management pattern used to separate a problem space into concern areas.  It
is for this reason that we have separate interfaces for our lifecycle methods.
We shouldn't have to implement a method if we have no use for it.  But it
doesn't stop there.  Separating interface from implementation helps separate
the concern of problem definition from problem solution.  Many concerns are
discrete; they have defined boundaries that only affect a small portion of the
problem space.  Other concerns are cross-cutting; they affect the whole
application, or at least a large part of the application.  Another word for
concerns are Aspects.  We can apply aspects without the need for language
modifying libraries like Aspect4J.  CBD provides the perfect way to apply
aspects to an application: through the container managing the components.

I think this pattern of SOC has been lost, but I think I have a way where we
can bring it back.

                   -o0= The Basics of a Container =0o-

In an effort to restore *simplicity*, let's get back to what the minimum is for
a container to do.  The absolute minimum for a container is to instantiate and
run one component.  That is all that is required for something to be a
container.  In fact we can boil the simplist container in the world down to one
very simple object:

public class Container
{
     private Component m_component;

     public Container()
     {
         m_component = new Component();
     }

     public Component getComponent();
}


That is the simplist container for the simplist component.  We start adding
complexity when we don't omnisciently know everything about our component.  For
that reason we have a collection of framework APIs so that the arbitrary
component knows how to get the information it needs, and the container can
initialize any arbitrary component.

We can expand this by providing a ComponentFactory which takes care of the
logic necessary to set up components.  The simplest implementation does not
require any external information.  It will use default objects for every stage.
The container can swap out the component factories, and the same container will
be able to work on a different kind of component.  I am oversimplifying this on
purpose.  Remember, this is a back to basics thought.

So far, we have a core container with the ability to swap out the
ComponentFactory.  Now what if we had another requirement to have multiple
ways of managing component instances?  I dubbed this concept "lifestyle", and
the term has kind of stuck.  Most containers work with a known lifestyle like
EJBs and Servlets, however ECM originally introduced the ability to have pooled
components and transient components.  The way these components are written is
incompatible with assuming singleton status.

There are a number of ways to solve that problem, but for now lets just classify
it as an aspect of component management.  So far we have identified two aspects.
There is no particular alegence to the ComponentFactory solution above, just a
recognition that component initialization logic is merely one of the concerns
from a component.

Another concern that is related to creating a component is populating the
lifecycle artifacts.  In Avalon land, the lifecycle artifacts are the Context
object, the ServiceManager, the Logger, etc.  The important thing to realize is
that this aspect is related to component initialization.  If our container is
able to initialize other types of components, the set of lifecycle artifacts
required will change.

Up to this point, our hypothetical container only has to maintain one component.
As soon as we introduce other components into the container, we have one more
aspect that needs to be managed: intercomponent dependencies.  These
dependencies can be managed by explicit logic, implicit logic, or some
combination.  For example, in ECM it is assumed that the developer knows all the
components that belong in the system.  In the more sophisticated containers, we
can verify that assumption is indeed true or not.  Also, in the more
sophisticated containers we provide an additional assembly concern.  Assembly
is the process of customizing how the container maps objects to dependencies.
The two levels of the mapping include components to component dependencies and
lifecycle artifacts to artifact dependencies.

So boiling a container into its most basic concern areas, we have the ability to
create and initialize a component, the ability to manage its lifestyle,
establishing the lifecycle artifacts, and managing intercomponent dependencies.
Everything else above these most basic concerns are features.  Many time these
features are necessary.  Many times these features are only really important to
a handful of people.  Either way, it is not important.  What *is* important is
that a container be able to add or modify these features in a manageable way.

                      -o0= The Radical Stuff =0o-

In Avalon land we have three modern containers: Fortress, Merlin, and Phoenix.
Each have their own strengths and weaknesses.  Each has tried new and exciting
approaches to different problems.  The truth be told, the only way to have a
one-size-fits-all container is not have one--at least in the traditional sense.
Our existing containers have addressed modularity in differing ways.  In the
end I find that a great learning experience.  We can find how things work, and
how to get things to interoperate.

This RRT works for both Avalon and Avalon#.  My proposal is this: start with
just the basics.  Make the basics interchangable.  That way we can define an
interface for the basics.  We can define how the basics interact.  We make it
really simple.  We don't identify the meta information ahead of time, we just
start with the logic.

Once we have the basic interfaces, we start providing the implementations
refactored from our existing containers.  Again, these are only the basics.
Once we have defined the functional basics, we look at what meta information
makes sense for that aspect.  The entire concern is self contained.  If we
want avalon components, the component initialization logic knows how to read
the meta information and provide it.  If we want our context objects verified,
we add in the concern which also reads that meta information.

In the end, our container becomes merely a shell that holds container
components.  Those container components interact to manage the application
components.  To differing levels of success, each of our containers has this
concept at heart.  The trick is to complete the job.  I believe we should start
fresh for the core code.  From there we refactor the existing containers to work
with that framework.  I believe we will be amazed at how quickly we can arrive
at the unification.  The trick is to start simple, and try to remain simple.

One approach is to declare a unique interface for each type of aspect.  Another
approach is to try to come up with one interface that is flexible enough to be
used in any aspect.  I leave it to the community to decide what the best
approach should be.

As we design our system we need to provide for some hard problems such as
interceptors, customizing parts of the lifecycle artifacts (i.e. one user may
want context validation but not configuration validation and vice versa).  We
don't have to get it right to begin with, the container components can evolve
as we find what works and what doesn't.

Now here is the truly radical part.  If we go this way, we don't have to come
up with one meta-info library that knows all about Avalon components and every
facet to them.  We only need a way to read arbitray metainfo from from the
component and assembly information.  As to assembly, we should make that concern
replaceable as well.  What we start with may not be what we end up with.  The
beauty of the solution is that the container can be free to be extended and
improved while still providing that key backwards compatibility.

As of right now, we don't have one way of doing assembly.  In fact, that should
be OK.  As long as we don't have to have a whole new container to implement an
alternative way of doing assembly we can let the user decide that they want the
container to use Phoenix Assembly rules with Merlin Component Management rules
and Fortress Asynchronous initialization.  Wouldn't that rock?  It allows the
evolution to move at a steady yet controlled rate so that the project neither
stagnates nor changes too radically.

                 -o0= Community Agreement Process =0o-

As has been shown repeatedly in the past, we will come up against issues where
we disagree.  What I would like to propose here is a guideline to help the
disagreement from escalating to the point it just did with the meta information
package.  The requirements of building a new container from the ground up,
evolving existing functionality in can have some potential points of conflict.
The Jakarta guidelines don't address this, and are insufficient when we are
dealing with design issues as opposed to code issues.  Design is reflected in
code so there is somewhat of a grey area there.  The balance is that interfaces
should be considered design, and implementation should be considered code.
For code (i.e. implementation) we follow Jakarta Guidelines.  For design (i.e.
interface) we follow the proposed guidelines:

* We put one or more proposals on the table for the same concern area.  The
   concern area should be clearly identified.

* Once all _questions_ have been answered about the differing proposals, and
   the proposals are finished with any modifications due to the questions,
   we place it up for vote.  The proposal that wins, wins.  No exceptions.
   Remember, we can change it later if we find it a dead end.

As to general guidelines to make this a happier place, I believe it is important
to lay down some general reminders.  Email is notoriously impersonal, even jests
can be taken in offense.

* Acknowlege and respect each others oppinions, comments, concerns.  Do not
   dismiss them, but you can address them in a calm unconfrontational manner.

* Offense happens.  When it does, simply say that a particular comment is
   offensive.  The person who offended needs to have the decency to acknowlege
   the hurt and appologize for it.  You can appologize for HOW you said something
   without appologizing for the INTENT of the message.  In other words, if your
   objection to an interface included offensive comments, you can appologize for
   the offensive comments without appologizing for objecting to the interface.

* Steer clear of calling each other's oppinions, comments, concerns FUD.
   Whether they are or not, remember the first point.

                          -o0= Are We on Board? =0o-

The body of this entire RRT includes my views on the subject, but that does not
mean we all agree to it.  The bottom line is that as long as we have code that
certain developers feel they need to protect from other developers we have no
basis for cooperation.  One way to address this issue is to equalize the playing
field and put everyone in the same boat.  Another way to address it is for us
to put down our pride and learn to work with everyone here.  Nothing is sacred.

As this affects the whole of Avalon, I would like to know your thoughts,
comments, concerns on this subject.  If we would like to adopt it as our future
direction, let's do it.  If there are any concerns, let's lay them on the table.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin



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

Re: [RRT] Getting back to the basics (long)

[Stephen McConnell <mc...@apache.org>]

Stephen McConnell wrote:

> As you known Berin - I have raised a veto against the changes you have 
> proposed. The veto notification was submitted to the PMC yesterday. I 
> also mentioned a number of options available to anyone that ensure 
> that there is [NO] stalemate here. If anyone would like to receive a 
> copy of the veto notification - I am quite happy to post it to the 
> list. As far as I am concerned - that issue is closed. 


Woops - a small correction included in the above paragraph.

Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

Re: [RRT] Getting back to the basics (long)

[Stephen McConnell <mc...@apache.org>]

Berin Loritsch wrote:

> Stephen McConnell wrote:
>
>
>>
>> Included in your RRT was the subject of a "Community Agreement 
>> Process". In that description you suggested that Jakarta rules are 
>> insufficient (a point I would contest). Within those guideline you 
>> proposed something that in my view attempts to engineer the direction 
>> of the community.
>>
>> Berin Loritsch wrote (original post):
>>
>>> * Once all _questions_ have been answered about the differing 
>>> proposals, and
>>> the proposals are finished with any modifications due to the questions,
>>> we place it up for vote. The proposal that wins, wins. No exceptions.
>>
>>
>>
>>
>> This set up rules - it changes the scope of what people here can do. 
>> I states that the community must follow without exception. That is a 
>> equivalent to modification of the charter. What happens if someone 
>> does something inside the scope of existing Avalon charter but 
>> outside the scope of the "plan". Are they expelled from Avalon? Are 
>> they coerced into doing things they don't want to do? Or will they 
>> simply be pushed out by a select few. These are fundamental issues 
>> that impact the community and our freedom to work within the charter 
>> that has been established by the Apache Board.
>
>
> Gee, here is a radical idea: instead of wondering what happens to them,
> just take it for what it was meant. A way to get past stalemates. If
> we all agree to it, then there is no issue. These types of questions
> make me believe you intend on making a big deal out of things.


Berin:

I'm focussing here on the implications of the procedures and attempting 
to point out that the procedures themselves can be detrimental to the 
community at a social level, and that suggesting that this could have a 
negative impact on how things evolve here at Avalon. But then again I 
don't have a degree in group behavior or social science.

>
>> The alternative is to respect the community as a process from which 
>> things emerge - promote and support the best of those and learn from 
>> the rest.
>
>
>
> Objections duly noted. However, consider my last attempt to work with you
> on the Avalon meta project in sandbox. Instead of escalating a stalemate,
> we are providing an out. Community rules--whether in your favor or mine
> or someone else's it doesn't matter. 


As you known Berin - I have raised a veto against the changes you have 
proposed. The veto notification was submitted to the PMC yesterday. I 
also mentioned a number of options available to anyone that ensure that 
there is stalemate here. If anyone would like to receive a copy of the 
veto notification - I am quite happy to post it to the list. As far as I 
am concerned - that issue is closed.

Lets move on - I outlined a few ideas towards the end of this email.

>
>
>
>>>>
>>>> Instead - let thing evolve because this community wants them to 
>>>> evolve. As you know, I'm quite keen on seeing the development here 
>>>> in Avalon of a common containment API but I'm also opposed to the 
>>>> notion of one container. In fact the vision I like is the ability 
>>>> to pull in a container matching your own needs - dynamically. Its a 
>>>> vision with lots of commonality with your own thoughts. But if we 
>>>> put down a rule that said there must one and only one container - 
>>>> we would immediately in conflict. The problem here is that rules 
>>>> force us into directions which we may not want to go. Underlying 
>>>> this is the problem that rules can used to coerce members of the 
>>>> community in unforeseen ways.
>>>
>>>
>>> Any issues with the vision in general other than the one container 
>>> issue? 
>>
>>
>>
>>
>> * I'm not interested in a start from scratch scenario
>> * Instead build on what we have based on shared objectives
>> * Opposed to the Community Agreement Process in general
>>
>> There may be other issues - but these these leap out at me!
>
>
> Again. Your issues are duly noted. As to point two, I believe
> that is the main reason why we are stalemated and not moving
> forward. We don't seem to have shared objectives.


I think we do. In fact I think you hinted at this earlier in the week 
when you mentioned that the work on the meta-info framework represents 
90% of what you wanted. I figure that 90% represents a lot of shared 
space - and that's a good result.

>
>>>> Another approach is to encourage and foster the contributions of 
>>>> developers here at Avalon based on shared objectives - and through 
>>>> this, facilitate the evolution of best-of-breed solutions. To 
>>>> enable adventure, good times, and great results.
>>>>
>>>> There are some things we can do to facilitate this:
>>>>
>>>> * get rid of the notion of managing the community (less stress)
>>>> * introduce a vibrant release process (frequent releases)
>>>> * encourage experiments (more surprises)
>>>> * capture and promote the best of breed (recognition)
>>>
>>>
>>>
>>>
>>> I could have swarn that I had 3 out of 4 of those nailed. As to
>>> managing the community, I believe this is largely a misconception. 
>>
>>
>> If you want to propose a project for sandbox - then cool - from there 
>> you can work towards what you have in mind. It does not really fit 
>> within my own view of where we are heading so I guess I want be an 
>> interested observer. But if you introduce the notion of rules - your 
>> kind of twisting my arm to work within the context of something I 
>> haven’t bought into. Remember - you said - "No Exception". That's 
>> attempting to engineer community direction and that's simply not what 
>> we should be attempting to doing.
>
>
> Thank you for putting words in my mouth, and implying motivations I
> don't have.


My comment was not directed towards your motivation nor do I want to put 
words into your mouth. I am simply making an observation of other 
approaches you could take, and noting implications of a "No Exception". 
It's probably fair to make the assumption that my approach is going to 
be somewhat more liberal than own. But that's just a reflection of who 
we are.

>
>>
>> Instead – think about shared objectives.
>
>
> Please list these, because every time I think I know what they are,
> you come along and blow away my view of what the shared objectives are. 


Like I said above - we see eye-to-eye on 90% in one particular example. 
I'm confident that there will other examples with equally high levels of 
mutual interest. That does not mean we need to agree right down to the 
last 1% - its just a case of leveraging the things that are mutually 
useful while maintaining a respect for the right of each and everyone 
here to hold differing options.

>
>>> I want to focus on something here. I want to move toward something
>>> good. I have a ton of ideas, but if I am the only one with them then
>>> what's the use? 
>>
>>
>> Not a lot.
>>
>> Why not try working with some of the other actives going on and see 
>> what you could contribute?
>
>
> Tried that, got yelled at. Not interested in getting yelled at anymore.
>
> So. Promise not to yell, and I will help you out. Otherwise we need to
> look at other activities.


Your help is always appreciated and I encourage you and everyone else 
here in Avalon to get involved in the things that are going on that 
interests them. I confident that with a little more relaxed atmosphere 
we will make great progress. I have a bunch of things that I would love 
to talk to about on the subject of the Merlin activation package with 
respect to thread management events and so on.

>
>
>>> Also, it is clear that status quo of little islands operating to 
>>> themselves
>>> is not working. That requires some management. I am looking for a 
>>> way that
>>> lets us to kick-A stuff with the minimal amount of friction/management
>>> necessary. It is important to realize that you as a PMC member are 
>>> equally
>>> charged with managing this community as I am.
>>
>>
>> Yep - and in my capacity as PMC member I have already put forward 
>> some recommendations. Notable amongst those recommendations was the 
>> issue of community engineering and the negative impact this has on 
>> members of the community. I also addressed priorities facilitating 
>> community growth and development. Underscoring that proposal is my 
>> firm belief that this community does not need the type of management 
>> your describing.
>
>
> I think I've said enough on the subject--everything I say keeps getting
> twisted somewhere between where I put the suggestions down and you 
> respond.
> I'm tired of that, so I'm not rehashing it anymore.


I'm not trying to twist anything - I sorry if I gave impression.

I understand what you trying to do and we have very similar aims. The 
means to get there are the subjects I'm addressing. We do have different 
views on things - and honestly - that's what makes us interesting as 
people and as a community.

>
>>> As to the community guidelines I put forth in the RRT, I thought 
>>> that they
>>> encouraged best of breed recognition. The idea for the container 
>>> outline
>>> encouraged experiments--some of them could be quite wild. And all of 
>>> this
>>> would require a vibrant release process.
>>
>>
>> So in effect what exists here in Avalon today is what you are aiming 
>> for. We have experiments - some of which are wilder than others. But 
>> I must confess - our release process is rather stale. But I'll be 
>> getting on to that ASAP.
>>
>
> Not exactly. What we have in Avalon is a fairly disjointed picture so 
> far.
> There are some common points, and we should be very happy about that. 
> What
> we don't have is a model where a component developer can freely go 
> between
> all Avalon containers and expect everything to work properly. That has 
> been
> my cheif short-term goal. However, every time I attempt that goal I meet
> opposition. SOmething is wrong. What is wrong is not technical in nature,
> but management related. Tell me, what do I have to do... and "live and 
> let
> live" isn't the answer.


I can tell what I think would be absolutely terrific.

Well, I think I've mentioned this before - I've been working away on a 
separation of meta-model from the assembly and deployment layers in 
Merlin. This is all groundwork for Merlin 3.0. In the CVS the 
composition package is all about bringing together meta-info descriptors 
with meta-data directives to create a formal deployment model. Focus 
here is to provide a model that can be managed via JMX. Above the 
composition package is the activation package - but that's local on my 
machine and is only dealing with assembly at this stage. In fact under 
Merlin 3.0 there is nothing supporting actual deployment. What I was 
planning on was to bring in an improvement of model in Merlin 2.1, but I 
wanted to get your ideas in about async. management into the picture 
before going to far.

Well - is something to think about.

Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

Re: [RRT] Getting back to the basics (long)

[Berin Loritsch <bl...@apache.org>]

Stephen McConnell wrote:


> 
> Included in your RRT was the subject of a "Community Agreement Process". 
> In that description you suggested that Jakarta rules are insufficient (a 
> point I would contest). Within those guideline you proposed something 
> that in my view attempts to engineer the direction of the community.
> 
> Berin Loritsch wrote (original post):
> 
>> * Once all _questions_ have been answered about the differing 
>> proposals, and
>> the proposals are finished with any modifications due to the questions,
>> we place it up for vote. The proposal that wins, wins. No exceptions.
> 
> 
> 
> This set up rules - it changes the scope of what people here can do. I 
> states that the community must follow without exception. That is a 
> equivalent to modification of the charter. What happens if someone does 
> something inside the scope of existing Avalon charter but outside the 
> scope of the "plan". Are they expelled from Avalon? Are they coerced 
> into doing things they don't want to do? Or will they simply be pushed 
> out by a select few. These are fundamental issues that impact the 
> community and our freedom to work within the charter that has been 
> established by the Apache Board.

Gee, here is a radical idea: instead of wondering what happens to them,
just take it for what it was meant.  A way to get past stalemates.  If
we all agree to it, then there is no issue.  These types of questions
make me believe you intend on making a big deal out of things.

> 
> The alternative is to respect the community as a process from which 
> things emerge - promote and support the best of those and learn from the 
> rest.


Objections duly noted.  However, consider my last attempt to work with you
on the Avalon meta project in sandbox.  Instead of escalating a stalemate,
we are providing an out.  Community rules--whether in your favor or mine
or someone else's it doesn't matter.


>>>
>>> Instead - let thing evolve because this community wants them to 
>>> evolve. As you know, I'm quite keen on seeing the development here in 
>>> Avalon of a common containment API but I'm also opposed to the notion 
>>> of one container. In fact the vision I like is the ability to pull in 
>>> a container matching your own needs - dynamically. Its a vision with 
>>> lots of commonality with your own thoughts. But if we put down a rule 
>>> that said there must one and only one container - we would 
>>> immediately in conflict. The problem here is that rules force us into 
>>> directions which we may not want to go. Underlying this is the 
>>> problem that rules can used to coerce members of the community in 
>>> unforeseen ways.
>>
>> Any issues with the vision in general other than the one container issue? 
> 
> 
> 
> * I'm not interested in a start from scratch scenario
> * Instead build on what we have based on shared objectives
> * Opposed to the Community Agreement Process in general
> 
> There may be other issues - but these these leap out at me!

Again. Your issues are duly noted.  As to point two, I believe
that is the main reason why we are stalemated and not moving
forward.  We don't seem to have shared objectives.


>>> Another approach is to encourage and foster the contributions of 
>>> developers here at Avalon based on shared objectives - and through 
>>> this, facilitate the evolution of best-of-breed solutions. To enable 
>>> adventure, good times, and great results.
>>>
>>> There are some things we can do to facilitate this:
>>>
>>> * get rid of the notion of managing the community (less stress)
>>> * introduce a vibrant release process (frequent releases)
>>> * encourage experiments (more surprises)
>>> * capture and promote the best of breed (recognition)
>>
>>
>>
>> I could have swarn that I had 3 out of 4 of those nailed. As to
>> managing the community, I believe this is largely a misconception. 
> 
> If you want to propose a project for sandbox - then cool - from there 
> you can work towards what you have in mind. It does not really fit 
> within my own view of where we are heading so I guess I want be an 
> interested observer. But if you introduce the notion of rules - your 
> kind of twisting my arm to work within the context of something I 
> haven’t bought into. Remember - you said - "No Exception". That's 
> attempting to engineer community direction and that's simply not what we 
> should be attempting to doing.

Thank you for putting words in my mouth, and implying motivations I
don't have.

> 
> Instead – think about shared objectives.

Please list these, because every time I think I know what they are,
you come along and blow away my view of what the shared objectives are.


>> I want to focus on something here. I want to move toward something
>> good. I have a ton of ideas, but if I am the only one with them then
>> what's the use? 
> 
> Not a lot.
> 
> Why not try working with some of the other actives going on and see what 
> you could contribute?

Tried that, got yelled at.  Not interested in getting yelled at anymore.

So. Promise not to yell, and I will help you out.  Otherwise we need to
look at other activities.


>> Also, it is clear that status quo of little islands operating to 
>> themselves
>> is not working. That requires some management. I am looking for a way 
>> that
>> lets us to kick-A stuff with the minimal amount of friction/management
>> necessary. It is important to realize that you as a PMC member are 
>> equally
>> charged with managing this community as I am.
> 
> Yep - and in my capacity as PMC member I have already put forward some 
> recommendations. Notable amongst those recommendations was the issue of 
> community engineering and the negative impact this has on members of the 
> community. I also addressed priorities facilitating community growth and 
> development. Underscoring that proposal is my firm belief that this 
> community does not need the type of management your describing.

I think I've said enough on the subject--everything I say keeps getting
twisted somewhere between where I put the suggestions down and you respond.
I'm tired of that, so I'm not rehashing it anymore.

>> As to the community guidelines I put forth in the RRT, I thought that 
>> they
>> encouraged best of breed recognition. The idea for the container outline
>> encouraged experiments--some of them could be quite wild. And all of this
>> would require a vibrant release process.
> 
> So in effect what exists here in Avalon today is what you are aiming 
> for. We have experiments - some of which are wilder than others. But I 
> must confess - our release process is rather stale. But I'll be getting 
> on to that ASAP.
> 

Not exactly.  What we have in Avalon is a fairly disjointed picture so far.
There are some common points, and we should be very happy about that.  What
we don't have is a model where a component developer can freely go between
all Avalon containers and expect everything to work properly.  That has been
my cheif short-term goal.  However, every time I attempt that goal I meet
opposition.  SOmething is wrong.  What is wrong is not technical in nature,
but management related.  Tell me, what do I have to do... and "live and let
live" isn't the answer.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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

Re: [RRT] Getting back to the basics (long)

[Stephen McConnell <mc...@apache.org>]

Berin Loritsch wrote:

> Stephen McConnell wrote:
>
>>
>>
>> Berin Loritsch wrote:
>>
>>> As this affects the whole of Avalon, I would like to know your 
>>> thoughts,
>>> comments, concerns on this subject. If we would like to adopt it as 
>>> our future
>>> direction, let's do it. If there are any concerns, let's lay them on 
>>> the table. 
>>
>>
>>
>>
>> We have a charter that states what Avalon is about - "service and 
>> component management".
>>
>> Within that scope there an infinite number of possibilities. However, 
>> when we consider community dynamics, the interests of different 
>> users, and personal objectives, we see a tendency of people to move 
>> towards concepts that interest them. And from time-to-time we move 
>> from one center-of-gravity to another. In effect, this represent the 
>> migration of interests drawn by the emergence of new ideas, solutions 
>> or opportunities.
>>
>> Here are my thoughts about the big picture from this perspective:
>>
>> Stop the process of *forced* convergence.
>> -----------------------------------------
>>
>> * Nobody here wants to be forced to do anything.
>> * Its driving people away.
>> * Its not focussing on needs.
>
>
> I'm sorry, I wasn't aware that the RRT was forcing convergence. Just
> trying to generate healthy conversation. 


Included in your RRT was the subject of a "Community Agreement Process". 
In that description you suggested that Jakarta rules are insufficient (a 
point I would contest). Within those guideline you proposed something 
that in my view attempts to engineer the direction of the community.

Berin Loritsch wrote (original post):

> * Once all _questions_ have been answered about the differing 
> proposals, and
> the proposals are finished with any modifications due to the questions,
> we place it up for vote. The proposal that wins, wins. No exceptions.


This set up rules - it changes the scope of what people here can do. I 
states that the community must follow without exception. That is a 
equivalent to modification of the charter. What happens if someone does 
something inside the scope of existing Avalon charter but outside the 
scope of the "plan". Are they expelled from Avalon? Are they coerced 
into doing things they don't want to do? Or will they simply be pushed 
out by a select few. These are fundamental issues that impact the 
community and our freedom to work within the charter that has been 
established by the Apache Board.

The alternative is to respect the community as a process from which 
things emerge - promote and support the best of those and learn from the 
rest.

>
>
>>
>> Instead - let thing evolve because this community wants them to 
>> evolve. As you know, I'm quite keen on seeing the development here in 
>> Avalon of a common containment API but I'm also opposed to the notion 
>> of one container. In fact the vision I like is the ability to pull in 
>> a container matching your own needs - dynamically. Its a vision with 
>> lots of commonality with your own thoughts. But if we put down a rule 
>> that said there must one and only one container - we would 
>> immediately in conflict. The problem here is that rules force us into 
>> directions which we may not want to go. Underlying this is the 
>> problem that rules can used to coerce members of the community in 
>> unforeseen ways.
>
>
> Any issues with the vision in general other than the one container issue? 


* I'm not interested in a start from scratch scenario
* Instead build on what we have based on shared objectives
* Opposed to the Community Agreement Process in general

There may be other issues - but these these leap out at me!

>
>
>>
>> Another approach is to encourage and foster the contributions of 
>> developers here at Avalon based on shared objectives - and through 
>> this, facilitate the evolution of best-of-breed solutions. To enable 
>> adventure, good times, and great results.
>>
>> There are some things we can do to facilitate this:
>>
>> * get rid of the notion of managing the community (less stress)
>> * introduce a vibrant release process (frequent releases)
>> * encourage experiments (more surprises)
>> * capture and promote the best of breed (recognition)
>
>
> I could have swarn that I had 3 out of 4 of those nailed. As to
> managing the community, I believe this is largely a misconception. 


If you want to propose a project for sandbox - then cool - from there 
you can work towards what you have in mind. It does not really fit 
within my own view of where we are heading so I guess I want be an 
interested observer. But if you introduce the notion of rules - your 
kind of twisting my arm to work within the context of something I 
haven’t bought into. Remember - you said - "No Exception". That's 
attempting to engineer community direction and that's simply not what we 
should be attempting to doing.

Instead – think about shared objectives.

>
>
> I want to focus on something here. I want to move toward something
> good. I have a ton of ideas, but if I am the only one with them then
> what's the use? 


Not a lot.

Why not try working with some of the other actives going on and see what 
you could contribute?

>
> Also, it is clear that status quo of little islands operating to 
> themselves
> is not working. That requires some management. I am looking for a way 
> that
> lets us to kick-A stuff with the minimal amount of friction/management
> necessary. It is important to realize that you as a PMC member are 
> equally
> charged with managing this community as I am.


Yep - and in my capacity as PMC member I have already put forward some 
recommendations. Notable amongst those recommendations was the issue of 
community engineering and the negative impact this has on members of the 
community. I also addressed priorities facilitating community growth and 
development. Underscoring that proposal is my firm belief that this 
community does not need the type of management your describing.

>
> As to the community guidelines I put forth in the RRT, I thought that 
> they
> encouraged best of breed recognition. The idea for the container outline
> encouraged experiments--some of them could be quite wild. And all of this
> would require a vibrant release process.


So in effect what exists here in Avalon today is what you are aiming 
for. We have experiments - some of which are wilder than others. But I 
must confess - our release process is rather stale. But I'll be getting 
on to that ASAP.

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

Re: [RRT] Getting back to the basics (long)

[Berin Loritsch <bl...@apache.org>]

Stephen McConnell wrote:

> 
> 
> Berin Loritsch wrote:
> 
>> As this affects the whole of Avalon, I would like to know your thoughts,
>> comments, concerns on this subject.  If we would like to adopt it as 
>> our future
>> direction, let's do it.  If there are any concerns, let's lay them on 
>> the table. 
> 
> 
> 
> We have a charter that states what Avalon is about - "service and 
> component management".
> 
> Within that scope there an infinite number of possibilities.  However, 
> when we consider community dynamics, the interests of different users, 
> and personal objectives, we see a tendency of people to move towards 
> concepts that interest them.  And from time-to-time we move from one 
> center-of-gravity to another. In effect, this represent the migration of 
> interests drawn by the emergence of new ideas, solutions or opportunities.
> 
> Here are my thoughts about the big picture from this perspective:
> 
> Stop the process of *forced* convergence.
> -----------------------------------------
> 
> * Nobody here wants to be forced to do anything.
> * Its driving people away.
> * Its not focussing on needs.

I'm sorry, I wasn't aware that the RRT was forcing convergence.  Just
trying to generate healthy conversation.

> 
> Instead - let thing evolve because this community wants them to evolve.  
> As you know, I'm quite keen on seeing the development here in Avalon of 
> a common containment API but I'm also opposed to the notion of one 
> container.  In fact the vision I like is the ability to pull in a 
> container matching your own needs - dynamically.  Its a vision with lots 
> of commonality with your own thoughts.  But if we put down a rule that 
> said there must one and only one container - we would immediately in 
> conflict.  The problem here is that rules force us into directions which 
> we may not want to go.  Underlying this is the problem that rules can 
> used to coerce members of the community in unforeseen ways.

Any issues with the vision in general other than the one container issue?

> 
> Another approach is to encourage and foster the contributions of 
> developers here at Avalon based on shared objectives - and through this, 
> facilitate the evolution of best-of-breed solutions.  To enable 
> adventure, good times, and great results.
> 
> There are some things we can do to facilitate this:
> 
> * get rid of the notion of managing the community (less stress)
> * introduce a vibrant release process (frequent releases)
> * encourage experiments (more surprises)
> * capture and promote the best of breed (recognition)

I could have swarn that I had 3 out of 4 of those nailed.  As to
managing the community, I believe this is largely a misconception.

I want to focus on something here.  I want to move toward something
good.  I have a ton of ideas, but if I am the only one with them then
what's the use?

Also, it is clear that status quo of little islands operating to themselves
is not working.  That requires some management.  I am looking for a way that
lets us to kick-A stuff with the minimal amount of friction/management
necessary.  It is important to realize that you as a PMC member are equally
charged with managing this community as I am.

As to the community guidelines I put forth in the RRT, I thought that they
encouraged best of breed recognition.  The idea for the container outline
encouraged experiments--some of them could be quite wild.  And all of this
would require a vibrant release process.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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

Re: [RRT] Getting back to the basics (long)

[Stephen McConnell <mc...@apache.org>]

Berin Loritsch wrote:

> As this affects the whole of Avalon, I would like to know your thoughts,
> comments, concerns on this subject.  If we would like to adopt it as 
> our future
> direction, let's do it.  If there are any concerns, let's lay them on 
> the table. 


We have a charter that states what Avalon is about - "service and 
component management".

Within that scope there an infinite number of possibilities.  However, 
when we consider community dynamics, the interests of different users, 
and personal objectives, we see a tendency of people to move towards 
concepts that interest them.  And from time-to-time we move from one 
center-of-gravity to another. In effect, this represent the migration of 
interests drawn by the emergence of new ideas, solutions or opportunities.

Here are my thoughts about the big picture from this perspective:

Stop the process of *forced* convergence.
-----------------------------------------

* Nobody here wants to be forced to do anything.
* Its driving people away.
* Its not focussing on needs.

Instead - let thing evolve because this community wants them to evolve.  
As you know, I'm quite keen on seeing the development here in Avalon of 
a common containment API but I'm also opposed to the notion of one 
container.  In fact the vision I like is the ability to pull in a 
container matching your own needs - dynamically.  Its a vision with lots 
of commonality with your own thoughts.  But if we put down a rule that 
said there must one and only one container - we would immediately in 
conflict.  The problem here is that rules force us into directions which 
we may not want to go.  Underlying this is the problem that rules can 
used to coerce members of the community in unforeseen ways.

Another approach is to encourage and foster the contributions of 
developers here at Avalon based on shared objectives - and through this, 
facilitate the evolution of best-of-breed solutions.  To enable 
adventure, good times, and great results.

There are some things we can do to facilitate this:

* get rid of the notion of managing the community (less stress)
* introduce a vibrant release process (frequent releases)
* encourage experiments (more surprises)
* capture and promote the best of breed (recognition)

Cheers, Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

Re: [RRT] Getting back to the basics (long)

[Berin Loritsch <bl...@apache.org>]

hammett wrote:
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> 
>>As to Avalon#/.NET there will be two pieces:
>>
>>The framework, and the Container.
>>
>>WIth Avalon# we have a fresh slate to work with, so no legacy issues to
>>overcome.
> 
> 
> But the files I downloaded from CVS were so little that I though someone
> didn't update the CVS for some time...
> 
> 
>>I personally would like your contributions.  If you are more skilled with
>>the .NET side of the equation, your contributions would be most welcomed.
> 
> 
> I rewritten my project  (polyethylene) to work with Avalon/Fortress and I
> liked tha IOC desing. It was a nice way of building pieces that could be
> easily tested and together forms a complete working system. I didn't upload
> the newer version to sourceforge yet as I didn't tested it with Tomcat,
> Weblogic and WS yet. The Avalon# got my attention as should be nice to have
> this kind of framework in the M$ world.
> 

Excellent.  As to accepting contributions for the Java side, we are more
than happy.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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

Re: [RRT] Getting back to the basics (long)

[hammett <ho...@cimcorp.com.br>]

----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
> As to Avalon#/.NET there will be two pieces:
>
> The framework, and the Container.
>
> WIth Avalon# we have a fresh slate to work with, so no legacy issues to
> overcome.

But the files I downloaded from CVS were so little that I though someone
didn't update the CVS for some time...

> I personally would like your contributions.  If you are more skilled with
> the .NET side of the equation, your contributions would be most welcomed.

I rewritten my project  (polyethylene) to work with Avalon/Fortress and I
liked tha IOC desing. It was a nice way of building pieces that could be
easily tested and together forms a complete working system. I didn't upload
the newer version to sourceforge yet as I didn't tested it with Tomcat,
Weblogic and WS yet. The Avalon# got my attention as should be nice to have
this kind of framework in the M$ world.



hammett
MCAD
Meet Polyethylene at http://polyethy.sourceforge.net/



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

Re: [RRT] Getting back to the basics (long)

[Berin Loritsch <bl...@apache.org>]

hammett wrote:

> I don't follow your entire message, I don't know about developers
> "protecting code" issue and I suspect it was a "backstage's talk".
> 
> But as you wanted opnions I would like to say that I (and I don't know if
> I'm speaking only for myself) don't know how to help. Avalon# for instance
> should be a concrete implementation of a container, or should be the
> framework from which someone will develop a Fortress#, Merlin.net, etc? I
> could claim for a document but I don't believe in this approach. Talking is
> the most clever way of handle issues/doubts.

As to Avalon#/.NET there will be two pieces:

The framework, and the Container.

WIth Avalon# we have a fresh slate to work with, so no legacy issues to
overcome.

> 
> As a personal opnion I think I - and a lot of silent readers - could help
> more, but seems that not everyone would like contributions. To me should be
> great to be part of a team that builds so powerfull projects and I'll be
> proud for each line of code, or each design suggestion that I'd give.

I personally would like your contributions.  If you are more skilled with
the .NET side of the equation, your contributions would be most welcomed.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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

Re: [RRT] Getting back to the basics (long)

[hammett <ho...@cimcorp.com.br>]

----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>

> > I was wondering about "type checking". Seems that every check occurs in
the
> > type loading/initialization. Maybe this type checking could be done in a
> > transparent way using ContextBoundObject/Interception in .Net. Then just
a
> > simple "new" could fire every checking and no explicit type checking
would
> > be necessary. Anyway is too soon to say. If I'm in the right path
signalize
> > that and I would create some samples, tests, labs..
>
> TO be honest, I wouldn't want to port it over to .NET.  I think with .NET
we
> can explore some new territory where we don't need an object model for the
> meta information.  Esp. since in .NET the attributes are part of the
class.
> In Java things are a bit different in the short term.

Yes yes! I always thought in porting using attributes. No xinfo files, etc.
The code could be something like:

namespace Apache.Avalon.Playground
{
 using System;
 using Apache.Avalon.Attributes;

 [Component("primary-component", Lifestyle.Singleton)]
 public class Primary : IPrimaryService, IContextualizable
 {
  [RequiredContextEntry("file", typeof(System.IO.File))]
  public void Contextualize(Context context)
  {
  }
 }
}


I just don't about the Version as .net handles side-by-side execution. Or
maybe the dependencies could be specified in a assembly full name way.

> Part of the implications of the technical part of the RRT I put forth was
that
> in an ideal world, the object model for meta information would not be
needed.
> In fact, it would be limiting the potential of what the container could
do.

Maybe you're right. .Net assemblies includes dependency information, version
and other things meta project included.

> I think that .NET provides the clean slate we can start with to use the
ideas
> I set forth.

How about ContextBoundObjects ? When the container code will start to be
written?


hammett
MCAD
Meet Polyethylene at http://polyethy.sourceforge.net/



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

Re: [RRT] Getting back to the basics (long)

[Berin Loritsch <bl...@apache.org>]

hammett wrote:

> ----- Original Message -----
> From: "Stephen McConnell" <mc...@apache.org>
> 
>>I have basicaly no experience in C#' but there is an interest in
>>Merlin.net based on Merlin 3.0.  In the short term I was thinking to
>>myself about the avalon-sandbox/meta package in this context.  It's
>>small, complete, and is a excelent candidate for a building block of a
>>container framework.  It's basically a small set of imutable classes
>>that describe a component to a container. I would be really interested
>>in any feedback concerning the the package and any issues we may need to
>>deal with in the delivery of a C# version.
> 
> 
> I studied the meta project in avalon-sandbox. There are no problems porting
> it to .net. The only thing I could say is about the Type class as long as
> "Type" is a very common name in .net that represents every type (as java
> does using Class). But namespaces should handle it.
> 
> I was wondering about "type checking". Seems that every check occurs in the
> type loading/initialization. Maybe this type checking could be done in a
> transparent way using ContextBoundObject/Interception in .Net. Then just a
> simple "new" could fire every checking and no explicit type checking would
> be necessary. Anyway is too soon to say. If I'm in the right path signalize
> that and I would create some samples, tests, labs..

TO be honest, I wouldn't want to port it over to .NET.  I think with .NET we
can explore some new territory where we don't need an object model for the
meta information.  Esp. since in .NET the attributes are part of the class.
In Java things are a bit different in the short term.

Part of the implications of the technical part of the RRT I put forth was that
in an ideal world, the object model for meta information would not be needed.
In fact, it would be limiting the potential of what the container could do.

I think that .NET provides the clean slate we can start with to use the ideas
I set forth.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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

Re: [RRT] Getting back to the basics (long)

[hammett <ha...@uol.com.br>]

----- Original Message -----
From: "Stephen McConnell" <mc...@apache.org>

> I have basicaly no experience in C#' but there is an interest in
> Merlin.net based on Merlin 3.0.  In the short term I was thinking to
> myself about the avalon-sandbox/meta package in this context.  It's
> small, complete, and is a excelent candidate for a building block of a
> container framework.  It's basically a small set of imutable classes
> that describe a component to a container. I would be really interested
> in any feedback concerning the the package and any issues we may need to
> deal with in the delivery of a C# version.

I studied the meta project in avalon-sandbox. There are no problems porting
it to .net. The only thing I could say is about the Type class as long as
"Type" is a very common name in .net that represents every type (as java
does using Class). But namespaces should handle it.

I was wondering about "type checking". Seems that every check occurs in the
type loading/initialization. Maybe this type checking could be done in a
transparent way using ContextBoundObject/Interception in .Net. Then just a
simple "new" could fire every checking and no explicit type checking would
be necessary. Anyway is too soon to say. If I'm in the right path signalize
that and I would create some samples, tests, labs..


hammett
MCAD
Meet Polyethylene at http://polyethy.sourceforge.net/




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

Re: [RRT] Getting back to the basics (long)

[Stephen McConnell <mc...@apache.org>]

hammett wrote:

>----- Original Message ----- 
>From: "Stephen McConnell" <mc...@apache.org>
>  
>
>>My personal preference - a framework on which someone will develop a 
>>Fortress#, Merlin.net, ehatever.  But the bottom line is that its up to 
>>the developers that wrote and commit the code!
>>    
>>

Correction (my typing really sucks)

It is up to the developers that write and commit the code.
I.e. it is up to you - go with whatever you think is best!

:-)

Cheers, Stephen.

>Easy, easy! :-)
>
>  
>
>>I have basicaly no experience in C#' but there is an interest in 
>>Merlin.net based on Merlin 3.0.  In the short term I was thinking to 
>>myself about the avalon-sandbox/meta package in this context.  It's 
>>small, complete, and is a excelent candidate for a building block of a 
>>container framework.  It's basically a small set of imutable classes 
>>that describe a component to a container. I would be really interested 
>>in any feedback concerning the the package and any issues we may need to 
>>deal with in the delivery of a C# version. 
>>    
>>
>
>I'll check it tonight. Thanks!!
>
>
>hammett
>MCAD
>Meet Polyethylene at http://polyethy.sourceforge.net/
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

Re: [RRT] Getting back to the basics (long)

[hammett <ho...@cimcorp.com.br>]

----- Original Message ----- 
From: "Stephen McConnell" <mc...@apache.org>
> 
> My personal preference - a framework on which someone will develop a 
> Fortress#, Merlin.net, ehatever.  But the bottom line is that its up to 
> the developers that wrote and commit the code!

Easy, easy! :-)

> I have basicaly no experience in C#' but there is an interest in 
> Merlin.net based on Merlin 3.0.  In the short term I was thinking to 
> myself about the avalon-sandbox/meta package in this context.  It's 
> small, complete, and is a excelent candidate for a building block of a 
> container framework.  It's basically a small set of imutable classes 
> that describe a component to a container. I would be really interested 
> in any feedback concerning the the package and any issues we may need to 
> deal with in the delivery of a C# version. 

I'll check it tonight. Thanks!!


hammett
MCAD
Meet Polyethylene at http://polyethy.sourceforge.net/



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

Re: [RRT] Getting back to the basics (long)

[Stephen McConnell <mc...@apache.org>]

hammett wrote:

>I don't follow your entire message, I don't know about developers
>"protecting code" issue and I suspect it was a "backstage's talk".
>
>But as you wanted opnions I would like to say that I (and I don't know if
>I'm speaking only for myself) don't know how to help. Avalon# for instance
>should be a concrete implementation of a container, or should be the
>framework from which someone will develop a Fortress#, Merlin.net, etc? 
>

My personal preference - a framework on which someone will develop a 
Fortress#, Merlin.net, ehatever.  But the bottom line is that its up to 
the developers that wrote and commit the code!

>I
>could claim for a document but I don't believe in this approach. Talking is
>the most clever way of handle issues/doubts.
>  
>

Yep.

>
>As a personal opnion I think I - and a lot of silent readers - could help
>more, but seems that not everyone would like contributions. To me should be
>great to be part of a team that builds so powerfull projects and I'll be
>proud for each line of code, or each design suggestion that I'd give.
>

I have basicaly no experience in C#' but there is an interest in 
Merlin.net based on Merlin 3.0.  In the short term I was thinking to 
myself about the avalon-sandbox/meta package in this context.  It's 
small, complete, and is a excelent candidate for a building block of a 
container framework.  It's basically a small set of imutable classes 
that describe a component to a container. I would be really interested 
in any feedback concerning the the package and any issues we may need to 
deal with in the delivery of a C# version. 

Cheers, Steve.

>
>
>hammett
>MCAD
>Meet Polyethylene at http://polyethy.sourceforge.net/
>
>----- Original Message -----
>From: "Berin Loritsch" <bl...@apache.org>
>To: "Avalon Developers List" <de...@avalon.apache.org>
>Sent: Wednesday, July 30, 2003 1:44 PM
>Subject: [RRT] Getting back to the basics (long)
>
>
>  
>
>>RRT = Radical Random Thought
>>
>>The body of this entire RRT includes my views on the subject, but that
>>    
>>
>does not
>  
>
>>mean we all agree to it.  The bottom line is that as long as we have code
>>    
>>
>that
>  
>
>>certain developers feel they need to protect from other developers we have
>>    
>>
>no
>  
>
>>basis for cooperation.  One way to address this issue is to equalize the
>>    
>>
>playing
>  
>
>>field and put everyone in the same boat.  Another way to address it is for
>>    
>>
>us
>  
>
>>to put down our pride and learn to work with everyone here.  Nothing is
>>    
>>
>sacred.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

Re: [RRT] Getting back to the basics (long)

[hammett <ho...@cimcorp.com.br>]

I don't follow your entire message, I don't know about developers
"protecting code" issue and I suspect it was a "backstage's talk".

But as you wanted opnions I would like to say that I (and I don't know if
I'm speaking only for myself) don't know how to help. Avalon# for instance
should be a concrete implementation of a container, or should be the
framework from which someone will develop a Fortress#, Merlin.net, etc? I
could claim for a document but I don't believe in this approach. Talking is
the most clever way of handle issues/doubts.

As a personal opnion I think I - and a lot of silent readers - could help
more, but seems that not everyone would like contributions. To me should be
great to be part of a team that builds so powerfull projects and I'll be
proud for each line of code, or each design suggestion that I'd give.


hammett
MCAD
Meet Polyethylene at http://polyethy.sourceforge.net/

----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Avalon Developers List" <de...@avalon.apache.org>
Sent: Wednesday, July 30, 2003 1:44 PM
Subject: [RRT] Getting back to the basics (long)


> RRT = Radical Random Thought
>
> The body of this entire RRT includes my views on the subject, but that
does not
> mean we all agree to it.  The bottom line is that as long as we have code
that
> certain developers feel they need to protect from other developers we have
no
> basis for cooperation.  One way to address this issue is to equalize the
playing
> field and put everyone in the same boat.  Another way to address it is for
us
> to put down our pride and learn to work with everyone here.  Nothing is
sacred.



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

Re: [RRT] Getting back to the basics (long)

[Leo Simons <le...@apache.org>]

Berin Loritsch wrote:
> RRT = Radical Random Thought

good one.

>                   -o0= The Basics of a Container =0o-
>                      -o0= The Radical Stuff =0o-

yep. Your last few e-mails and the response show to me that mindshare 
for a new way of doing things is reaching critical mass.

sidetracking a little...I would note that sharing with a .Net port can 
be sharing of concepts, ideas, and basic patterns, but from my limited 
experience the opportunity for code sharing is not so big, simply 
because the .Net platform provides a lot of features not available under 
java that make putting in place an advanced avalon-style container a lot 
more straightforward. In other words: .Net folks, your original thoughts 
and radical different implementations will be better than simple java ports.

>                 -o0= Community Agreement Process =0o-

ehm. Totally like the goal you have here and the general idea of trying
alternatives (start with the simplest thing that can possibly work,
discard when that doesn't work), dislike trying to formalize any new
rules. I don't think rules will help us.

>                          -o0= Are We on Board? =0o-

yep. Have been for a while, glad you're catching on :P Lets keep our
heads cool tho.

I have put some proof-of-concept stuff in my private sandbox at

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jicarilla/jicarilla-sandbox/platform/

I think it's worth a look of all devs here simply because its internals
are shaping up very differently from what we have here @ avalon. Of
course, with pico (whose internals I still have to take a look at), it
might be a lot less different to some already ;).

I have a mach-style microkernel providing async message management as
well, and another one providing classworld management, and some sketchy
container code invoking jython all over the place but I cut that out for
reasons of clarity.

I am going to do more experimentation in this little corner of the
world. Lets see how much of the concepts developed can be brought into
the fold over here.

greetz!

- Leo



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

Re: [RRT] Getting back to the basics (long)

[Berin Loritsch <bl...@apache.org>]

Stephen McConnell wrote:

> 
> As I mentioned to Berin - I'm not about to start over - simply because 
> there its just plain boring and a recepie for discontent.  Been there, 
> done that, want to continue on the really challenging stuff.  Think 
> about distributed containers, federated management, adaptive component 
> security.  This is the future - a future where it challenges the best or 
> our abilities - a future where we are not going over old ground 
> attempting to convince each other that direction X is the best direction.
> 
> Go for the challenges - its a lot more interesting.
> 

Don't think of it as starting over.  Think of it as refactoring the core
to make those really challenging things easier.

I would like to take a look at how the different containers organize things
in the core to see the strengths and weaknesses of each.  Leveraging that
information, we can provide for a better and refactored core that we all
know how to work with.

As to the list of challenges you have, I would like a little more info:

* Distributed containers: I think we understand this well enough
* Federated Management: I am not sure what you mean by this.
* Adaptive component security: Phoenix has a start on this I believe, or
                                are you talking about something different?


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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

Re: [RRT] Getting back to the basics (long)

[Stephen McConnell <mc...@apache.org>]

Berin Loritsch wrote:

> Stephen McConnell wrote:
>
>>
>>
>> Leo Sutic wrote:
>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Stephen McConnell [mailto:mcconnell@apache.org]
>>>> In addition, as a project is it dedicated to pushing back core
>>>
>>>
>>> reusable
>>>
>>>> technologies into a common container architecture - something that 
>>>> impacts everyone here.
>>>
>>>
>>>
>>> This is a good goal - try things out in separate containers and then
>>> merge back the code into the core.
>>>
>>> The problem is that such merges often take on the form:
>>>
>>> "This code works well in X. So we'll just put it in the core
>>> as it is, and no changes are allowed."
>>>
>>> Instead of looking at the concepts of that code, and, allowing it to
>>> change, get merged into the core:
>>>
>>> "These ideas works well in X, let's see if and when and in what form 
>>> we can get them into the core."
>>>
>>> I think this was what caused the last eruption.
>>>
>>
>> Historical correction:
>>
>> Lots of changes were mode to code in question as part of moving it 
>> out of Merlin and into Avalon Meta to accommodate everyone’s 
>> interests. A lot of time was spent refactoring the Merlin base to 
>> incorporate those changes. One particular proposal for change by 
>> Berin was block by veto from me on the grounds that it would be 
>> detrimental to the object model. If Berin really things that his 
>> proposed change must go through - then he can fork the project, pull 
>> a community around the fork, and propose something different. 
>> Alternatively, he can relax a little and accept that there is a 
>> perfectly good solution that meets 90% of needs. That's a decision 
>> that Berin needs to make.
>
>
> No, no,no,no,no!
>
> All forks must be approved by the PMC. 


Can you please provide a reference to a policy or procedure that the 
members of the PMC have agreed to that requires that a fork must be 
approved by the PMC.

Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

Re: [RRT] Getting back to the basics (long)

[Berin Loritsch <bl...@apache.org>]

Stephen McConnell wrote:

> 
> 
> Leo Sutic wrote:
> 
>>  
>>
>>> -----Original Message-----
>>> From: Stephen McConnell [mailto:mcconnell@apache.org]
>>> In addition, as a project is it dedicated to pushing back core
>>>   
>>
>> reusable  
>>
>>> technologies into a common container architecture - something that 
>>> impacts everyone here.
>>>   
>>
>>
>> This is a good goal - try things out in separate containers and then
>> merge back the code into the core.
>>
>> The problem is that such merges often take on the form:
>>
>>   "This code works well in X. So we'll just put it in the core
>>    as it is, and no changes are allowed."
>>
>> Instead of looking at the concepts of that code, and, allowing it to
>> change, get merged into the core:
>>
>>   "These ideas works well in X, let's see if and when and in what form 
>>    we can get them into the core."
>>
>> I think this was what caused the last eruption.
>>
> 
> Historical correction:
> 
> Lots of changes were mode to code in question as part of moving it out 
> of Merlin and into Avalon Meta to accommodate everyone’s interests. A 
> lot of time was spent refactoring the Merlin base to incorporate those 
> changes. One particular proposal for change by Berin was block by veto 
> from me on the grounds that it would be detrimental to the object model. 
> If Berin really things that his proposed change must go through - then 
> he can fork the project, pull a community around the fork, and propose 
> something different. Alternatively, he can relax a little and accept 
> that there is a perfectly good solution that meets 90% of needs. That's 
> a decision that Berin needs to make.

No, no,no,no,no!

All forks must be approved by the PMC.  The whole concept of forks and
"declaring a revolution" is why we have four different containers, lack
of community, and folks operating in relative ignorance of other things.

No vetos--I remember you lobbying for no vetos in the past.  You issue
of one (which I have failed to see on any list) is a hypocritical move.

As a PMC Chair, I declare that veto null and void.  It's only purpose is
to railroad your oppinion through.  State your objections, and find out
what others think.

We need to learn to work together.  Nothing I have presented affects the
object model, and has no implications whatsoever on the object model.

As to relax a little: that was my encouragement to you.  I have conceded
on many many points, except one.  It's a decision for you to make.  Learn
to work with others.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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

Re: [RRT] Getting back to the basics (long)

[Stephen McConnell <mc...@apache.org>]

Leo Sutic wrote:

>  
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org] 
>>
>>Please go back of the archives and look at the comments and and 
>>discussions relating to (a) AMTAGS, (b) the Merlin meta-info 
>>package and (c) the Avalon Meta package.
>>    
>>
>
>I have checked that. Those are the threads that degenerated into
>this fine mess and I don't consider them "discussion" - yes, a
>lot of emails have been flying back and forth, but I haven't found 
>any solid proposals or votes going through.
>

I'm not going to go running off to the archived to prove it for you - 
you need to do that yourself if you feel you need to.

Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

RE: [RRT] Getting back to the basics (long)

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Stephen McConnell [mailto:mcconnell@apache.org] 
>
> Please go back of the archives and look at the comments and and 
> discussions relating to (a) AMTAGS, (b) the Merlin meta-info 
> package and (c) the Avalon Meta package.

I have checked that. Those are the threads that degenerated into
this fine mess and I don't consider them "discussion" - yes, a
lot of emails have been flying back and forth, but I haven't found 
any solid proposals or votes going through.

/LS


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

Re: [RRT] Getting back to the basics (long)

[Stephen McConnell <mc...@apache.org>]

Leo Sutic wrote:

>  
>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@apache.org] 
>>Sent: den 31 juli 2003 14:51
>>To: Avalon Developers List
>>Subject: Re: [RRT] Getting back to the basics (long)
>>
>>
>>
>>
>>Leo Sutic wrote:
>>
>>    
>>
>>> 
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>>>
>>>>In addition, as a project is it dedicated to pushing back core
>>>>   
>>>>
>>>>        
>>>>
>>>reusable
>>> 
>>>
>>>      
>>>
>>>>technologies into a common container architecture - something that
>>>>impacts everyone here.
>>>>   
>>>>
>>>>        
>>>>
>>>This is a good goal - try things out in separate containers and then 
>>>merge back the code into the core.
>>>
>>>The problem is that such merges often take on the form:
>>>
>>>  "This code works well in X. So we'll just put it in the core
>>>   as it is, and no changes are allowed."
>>>
>>>Instead of looking at the concepts of that code, and, allowing it to 
>>>change, get merged into the core:
>>>
>>>  "These ideas works well in X, let's see if and when and 
>>>   in what form we can get them into the core."
>>>
>>>I think this was what caused the last eruption.
>>>
>>>      
>>>
>>Historical correction:
>>
>>Lots of changes were mode to code in question as part of moving it out
>>    
>>
>
>  
>
>>of Merlin and into Avalon Meta to accommodate everyone's interests.
>>    
>>
>
>Historical correction - Berin's needs weren't accomodated. This should
>be obvious.
>

You playing with words - go take a look at the CVS history and checkout 
the changes to the package and tell me that I havn't tried to accomade 
everyones intereests.  Berin's particular proposal was at odds with the 
technical integrity of the object model as I have already stated and 
because of this that proposal was not included.

>Historical correction - there was no public discussion of the code when
>it was being moved. If I slept through that discussion then this point
>is wrong and can be ignored.
>

Please go back of the archives and look at the comments and and 
discussions relating to (a) AMTAGS, (b) the Merlin meta-info package and 
(c) the Avalon Meta package.

>What happened was that you moved code from Merlin-specific to all-Avalon
>without any prior discussion because it worked in Merlin. 
>

The package was moved out following Berin's suggestion on that grounds 
that it could be used across both Merlin and Fortress. Do I have to 
provide evidence on this - seems like you want to hang me for something!

>Then you proceeded to declare the end of the world because that code would not be
>accepted as-is.
>

No - I simply did not agree with a proposal by Berin that would have 
created an inconsistency between the tag layer and the underlying object 
model.

>If I missed the discussion, and the move of code from Merlin to
>Avalon-Meta was based on a community (as in all of Avalon) decision, I shall
>promptly blow my head off with a howitzer or equivalent in shame, but I find no
>such discussion in the ML archives nor in my memory.
>  
>

Put away the artilary - and go back hunting in the archives.

Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

RE: [RRT] Getting back to the basics (long)

[Leo Sutic <le...@inspireinfrastructure.com>]

> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org] 
> Sent: den 31 juli 2003 14:51
> To: Avalon Developers List
> Subject: Re: [RRT] Getting back to the basics (long)
> 
> 
> 
> 
> Leo Sutic wrote:
> 
> >  
> >
> >>-----Original Message-----
> >>From: Stephen McConnell [mailto:mcconnell@apache.org]
> >>
> >>In addition, as a project is it dedicated to pushing back core
> >>    
> >>
> >reusable
> >  
> >
> >>technologies into a common container architecture - something that
> >>impacts everyone here.
> >>    
> >>
> >
> >This is a good goal - try things out in separate containers and then 
> >merge back the code into the core.
> >
> >The problem is that such merges often take on the form:
> >
> >   "This code works well in X. So we'll just put it in the core
> >    as it is, and no changes are allowed."
> >
> >Instead of looking at the concepts of that code, and, allowing it to 
> >change, get merged into the core:
> >
> >   "These ideas works well in X, let's see if and when and 
> >    in what form we can get them into the core."
> >
> >I think this was what caused the last eruption.
> >
> 
> Historical correction:
> 
> Lots of changes were mode to code in question as part of moving it out

> of Merlin and into Avalon Meta to accommodate everyone's interests.

Historical correction - Berin's needs weren't accomodated. This should
be obvious.

Historical correction - there was no public discussion of the code when
it was being moved. If I slept through that discussion then this point
is wrong and can be ignored.

What happened was that you moved code from Merlin-specific to all-Avalon
without any prior discussion because it worked in Merlin. Then you
proceeded to declare the end of the world because that code would not be

accepted as-is.

If I missed the discussion, and the move of code from Merlin to
Avalon-Meta
was based on a community (as in all of Avalon) decision, I shall
promptly 
blow my head off with a howitzer or equivalent in shame, but I find no
such
discussion in the ML archives nor in my memory.

/LS


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

Re: [RRT] Getting back to the basics (long)

[Stephen McConnell <mc...@apache.org>]

Leo Sutic wrote:

>  
>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@apache.org] 
>>
>>In addition, as a project is it dedicated to pushing back core
>>    
>>
>reusable 
>  
>
>>technologies into a common container architecture - something that 
>>impacts everyone here.
>>    
>>
>
>This is a good goal - try things out in separate containers and then
>merge back the code into the core.
>
>The problem is that such merges often take on the form:
>
>   "This code works well in X. So we'll just put it in the core
>    as it is, and no changes are allowed."
>
>Instead of looking at the concepts of that code, and, allowing it to
>change, get merged into the core:
>
>   "These ideas works well in X, let's see if and when and in what form 
>    we can get them into the core."
>
>I think this was what caused the last eruption.
>

Historical correction:

Lots of changes were mode to code in question as part of moving it out 
of Merlin and into Avalon Meta to accommodate everyone’s interests. A 
lot of time was spent refactoring the Merlin base to incorporate those 
changes. One particular proposal for change by Berin was block by veto 
from me on the grounds that it would be detrimental to the object model. 
If Berin really things that his proposed change must go through - then 
he can fork the project, pull a community around the fork, and propose 
something different. Alternatively, he can relax a little and accept 
that there is a perfectly good solution that meets 90% of needs. That's 
a decision that Berin needs to make.

Maybe we could let this drop. I think its been thrash over more than it 
deserves. Apache have rules about this sort of stuff. Lets respect those 
rules and move on.

Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

RE: [RRT] Getting back to the basics (long)

[Leo Sutic <le...@inspireinfrastructure.com>]

> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org] 
>
> In addition, as a project is it dedicated to pushing back core
reusable 
> technologies into a common container architecture - something that 
> impacts everyone here.

This is a good goal - try things out in separate containers and then
merge back the code into the core.

The problem is that such merges often take on the form:

   "This code works well in X. So we'll just put it in the core
    as it is, and no changes are allowed."

Instead of looking at the concepts of that code, and, allowing it to
change, get merged into the core:

   "These ideas works well in X, let's see if and when and in what form 
    we can get them into the core."

I think this was what caused the last eruption.

If anything, this is what we need to work on. Learning not to lock
ourselves
into our own idea just because we like it the most.

/LS


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

RE: [RRT] Getting back to the basics (long)

[Carsten Ziegeler <cz...@s-und-n.de>]

Stephen McConnell wrote:
>
> Carsten Ziegeler wrote:
>
> >Basically, I like the idea because by this it's possible to have a
> >real community development effort with avoiding the one-man shows etc.
> >
>
> The term "one-man show" is something that is possibly misplaced.
> <SNIP/>
>
I didn't refer to existing projects, it's just intended as a general
comment.
Anyway, let's not argue about that.

> >But this would only work if we could all agree on this.
> >
> >So what do others think?
> >
>
> < SNIP Stephens opinion />

So far, we have thoughts from Berin, Stephen, hammett, Christopher
and a little bit from me.

What about others?

Carsten


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

Re: [RRT] Getting back to the basics (long)

[Stephen McConnell <mc...@apache.org>]

Peter Royal wrote:

> On Thursday, July 31, 2003, at 08:13  AM, Stephen McConnell wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> So, if I understand this correctly, the idea is to start a new version
>>> from scratch (of course not really from scratch we already have
>>> the framework interfaces)?
>>>
>>> Basically, I like the idea because by this it's possible to have a 
>>> real community development effort with avoiding the one-man shows >> 
>>> etc.
>>
>
> Carsten, I agree with you.
>
>> As I mentioned to Berin - I'm not about to start over - simply 
>> because there its just plain boring and a recepie for discontent.  
>> Been there, done that, want to continue on the really challenging 
>> stuff.  Think about distributed containers, federated management, 
>> adaptive component security.  This is the future - a future where it 
>> challenges the best or our abilities - a future where we are not 
>> going over old ground attempting to convince each other that 
>> direction X is the best direction.
>
>
> Stephen, why was Merlin started, as opposed to branching/working 
> within the existing Phoenix codebase? 


Merlin actually started out in life as a little component runner that 
handled the problem of developing components under Phoenix. Phoenix was 
a remains a really heavy-weight tool when all you want to do is a 
runtime test. The idea was to to create an ant task that would take a 
target component and deploy it. In doing so it had to figure out 
depednecies and other stuff without forcing the developer to write a 
bunch of assembly files package the thing in a ar file, and lauch 
Phoenix.  That's was Merlin 1.0.

Merlin 2 emergaged as was a result of working with Peter Donald on the 
containerkit package.  That package was all about formalizing the 
component/container contract. Peter's work was largely focussed on the 
Phoenix requirements wheras my own requirements were more dynamic and 
included embedded scenarios - a subject not handled by any container 
solution available in Avalon at the time.   Over time, Merlin has 
developed to incorporate many end-user requirements relating to 
practical and simple service management.

>
>
> My opinion is that you wanted a codebase where you had control over it. 


No - not at all.

> And you have been positioning Merlin to be in a place to ascend to be 
> the primary Avalon container. 


Actually - if you go back to previuse posts I have consistently stated 
that I would like to see Merlin as a project that facilitates 
experimentation, and that through validation in the real word, there may 
perhaps be sub-system that can be proposed as common solutions. Merlin 
is just a project that can contributes to the bigger avalon picture in 
interesting ways.

Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

Re: [RRT] Getting back to the basics (long)

[Peter Royal <pr...@apache.org>]

On Thursday, July 31, 2003, at 08:13  AM, Stephen McConnell wrote:
> Carsten Ziegeler wrote:
>> So, if I understand this correctly, the idea is to start a new version
>> from scratch (of course not really from scratch we already have
>> the framework interfaces)?
>>
>> Basically, I like the idea because by this it's possible to have a 
>> real community development effort with avoiding the one-man shows >> etc.

Carsten, I agree with you.

> As I mentioned to Berin - I'm not about to start over - simply because 
> there its just plain boring and a recepie for discontent.  Been there, 
> done that, want to continue on the really challenging stuff.  Think 
> about distributed containers, federated management, adaptive component 
> security.  This is the future - a future where it challenges the best 
> or our abilities - a future where we are not going over old ground 
> attempting to convince each other that direction X is the best 
> direction.

Stephen, why was Merlin started, as opposed to branching/working within 
the existing Phoenix codebase?

My opinion is that you wanted a codebase where you had control over it. 
And you have been positioning Merlin to be in a place to ascend to be 
the primary Avalon container. You don't want to start over because you 
already started over all by yourself and did everything you wanted to 
without anyone else's input.

The disagreements this week have just show how you don't want to loose 
the iron grip that you have upon the Merlin codebase. The undermining 
of Berin's leadership also makes me thing that you want to run all of 
Avalon too. You're just trying to drain everyone else's energy.

Back when there were talking about a future roadmap for Avalon, you 
were all for creating a new container taking the best ideas from what 
we have. Now that one of Avalon's greatest contributors, and someone 
that was willing to stand up to you, has been effectively ousted, Berin 
is next in line to be frustrated and worn down.


There. I've said it.


What are you looking for? Merlin to be a released and supported Avalon 
container?

We all agreed that we wanted to move towards having a single container 
here at Avalon. We currently have two released containers. Three 
released containers is a big step backwards to me.

Perhaps Avalon would be better off with no containers of its own at all.

-pete "reaching that high level of frustration"


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

Re: [RRT] Getting back to the basics (long)

[Stephen McConnell <mc...@apache.org>]

Carsten Ziegeler wrote:

>Berin Loritsch wrote:
>< SNIP RRT >
>
>So, if I understand this correctly, the idea is to start a new version
>from scratch (of course not really from scratch we already have
>the framework interfaces)?
>
>Basically, I like the idea because by this it's possible to have a 
>real community development effort with avoiding the one-man shows etc.
>

The term "one-man show" is something that is possibly misplaced.  If the 
term refers to Phoenix - well its simply not case - Peter Donald 
initiated it and build a community of users and attracted developers to 
it.  As the branch of development because interesting it attracted other 
developers and things grew.  In the case of the Merlin project, your 
watching something that was initiated my myself - and over time has 
received contributions from Leo, Berin, Vinay, Marcus, Peter, Leif, 
Gary, Richard, Jörg, David, Kristian, Aaron , Laurent and probably 
others that I have missed.  The Merlin project has not been released yet 
due primarily to internal Avalon politics.  In spite of that, the 
project is growing - its community is expanding, and once we (Avalon) 
get past the politics - this expansion will accelerate significantly.  
In spite of a low contribution to noise ration from other more 
established committers, Merlin has gained a lot a user support. In 
addition, as a project is it dedicated to pushing back core reusable 
technologies into a common container architecture - something that 
impacts everyone here.

>But this would only work if we could all agree on this.
>
>So what do others think?
>

As I mentioned to Berin - I'm not about to start over - simply because 
there its just plain boring and a recepie for discontent.  Been there, 
done that, want to continue on the really challenging stuff.  Think 
about distributed containers, federated management, adaptive component 
security.  This is the future - a future where it challenges the best or 
our abilities - a future where we are not going over old ground 
attempting to convince each other that direction X is the best direction.

Go for the challenges - its a lot more interesting.

Cheers, Steve.

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

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

RE: [RRT] Getting back to the basics (long)

[Carsten Ziegeler <cz...@s-und-n.de>]

Berin Loritsch wrote:
< SNIP RRT >

So, if I understand this correctly, the idea is to start a new version
from scratch (of course not really from scratch we already have
the framework interfaces)?

Basically, I like the idea because by this it's possible to have a 
real community development effort with avoiding the one-man shows etc.
But this would only work if we could all agree on this.

So what do others think?

Carsten


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