Under Promise, Over Deliver

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

In my experiences with computing, the company's motto that impressed me
the most was Be, Inc.  Jean Louis Gasse' (sp?) was a genious for
promoting
the mindset of "Under Promise, Over Deliver".  For a commercial company
it really hampers the marketing department, but for an OSS project it is
the only mindset to have.

There are some key obstacles that seem to be in our way of achieving
this goal:

1) Over design, under simplification
2) Big ego, small content

The big ego, small content has already been hammered on, so we will try
to keep the signal to noise ratio down.

So far the most productive thread we have had was the "Fresh
Perspective",
as I finally got what Stephen and Peter were pushing (although at first
it was just Stephen).  There is a lot to like in it.

Our biggest problem is Over Design, Under Simplification.  The job of a
*usable* framework is to enable things to be done that otherwise could
not be done.  Avalon 4 does this quite well.  There are some things that
does not sit well with me in the track we are on for A5.  They are
listed
below:

1) The container specification is becoming quite complex.  The
complexity
   is hoped to be made up for by a "ContainerKit", but if someone wanted
   to discard the container kit and create their own container from
scratch
   it is approaching the level of needing a company to finance the
   proposition.  This is not good.

2) We are pushing *more* of the burden of design, thread safety issues,
   etc. on the component developer.  This is a *bad* choice.  ColdFusion
   4 tried to automatically handle the locking of CF script variables,
   but did a poor job of it.  Their solution was to offload that
   responsibility to the page developers.  By CF 4.5, we had a product
that
   needed to be revamped to explicitly handle locking of variables.  We
   are making the same mistake regarding pooling of components.

3) If anything, we want to make it *easier* to use.  Even better we want
   to make it *easier* to use correctly.  While it is a design goal to
   encourage good practices and discourage bad practices, we can't all
   do that at the interface level.  People follow examples, good or bad.

Now documentation and examples are something we can do in A4.  However
it
is the type of examples that need to make sense.  We need to demonstrate
*why* something is bad (performance, maintenance, scalability, etc.),
and
how to correct it *easily*.  Something like the J2EE BluePrint document
would be best.  We need to demonstrate how certain designs just work
better,
and aren't that much more difficult to do.

Some things are difficult to do.  Pooling components is a valid
proposition.
You could have fewer instances of components than threads of execution
(as
opposed to the more common case in Cocoon where there are multiple
instances per thread of execution).  However, removing the release()
method
has incredible consequences on existing code for only a little ease in
the container.

As Benjamin Franklin said, "They that give up essential liberty to
obtain a
little temporary safety deserve neither liberty nor safety."  While
it has more to do with patriotism than with development, it still
applies.

Unless we provide a fundamentally *better* approach that does not tax
our
users, the proposed approach is flawed.  It is like when England raised
taxes on American soil without giving them representation in parliament.
The Americans eventually revolted, casting all things English aside.  It
wasn't until much later that America and England could stand each other
enough to resume trade relations.

This is *not* what we want for Avalon.  Any freedom we remove *must*
be replaced with something better.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Make your stand now - Is Avalon for more than ReUse ?

[Peter Donald <pe...@apache.org>]

At 02:46 PM 6/20/2002 -0500, you wrote:
>Submitted this question within <flamebait/> earlier, but it got ignored. 
>It needs to be answered.
>
>Is Avalon for ANY other purpose than *Component Re-Use* or not? That is 
>certainly my only interest. It is arguably what attracts most people to 
>it? True or false?

My main draw card for me is that it gives me a ready-made template for 
application. However the template does not enforce any domain specific 
constraints or structure. Thus I can rapidly prototype applications and 
know I will be able to evolve them in the future with relative ease. So 
what I like is the quick initial implementation and the ability to scale up 
with minimal pain.

Reuse would be fantastic. There are large chunks of cocoon I would love to 
reuse in myrmidon but I can't as they are littered with Cocoon specific 
assumptions.

The main motivation for containerKit/metainfo stuff is that I will be able 
to cleanly reuse these things without effecting cocoons current usage.


Cheers,

Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
              - John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Make your stand now - Is Avalon for more than ReUse ?

[Stephen McConnell <mc...@osm.net>]

Pete Carapetyan wrote:

> Submitted this question within <flamebait/> earlier, but it got 
> ignored. It needs to be answered.
>
> Is Avalon for ANY other purpose than *Component Re-Use* or not? That 
> is certainly my only interest. It is arguably what attracts most 
> people to it? True or false?


Form the point of view of the internal architecture of our (OSM) 
devleopment, Avalon component *resuse* is not an absolute factor.  There 
are many situations where I am dealing with families of components 
within which I'm introducing behaviours that our outside of classic 
resuable components.  There are other cases - components intended to be 
*reused* as standalone services - but my usage of the work standalone is 
in the context of a formal component model - one in which "standalone* 
allows me to formally declare dependecies - formally declare services - 
in effect to formally declare how my component will successfull work 
with other formally declared components.

I do want reusable component from Avalon and I think this is 
fundimentally important. I also believe that the framework can provide 
much more than this - but if I had to back one single objective it would 
be reuse.

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Make your stand now - Is Avalon for more than ReUse ?

[Michael Stanley <ms...@mitre.org>]

My quick 2 cents  ->

I've followed the Avalon project (quitely) for some time.  I've 
experienced its use with projects like James and Cocoon, both of which 
I'm very familiar with.  I recently read all there is to read about 
Avalon (as I plan to use it on my new work project), including the 
source.  Let me say first off that I'm very impressed with the project, 
its goals, and its overall design.

To me Avalon is much more that Component Re-Use.  Avalon is a prime 
example of good software engineer and good OO practice.  It is a great 
patterns reference, and model for all component oriented programming.
Component Re-use is just an added benefit.

<Mike/>

Pete Carapetyan wrote:
> Submitted this question within <flamebait/> earlier, but it got ignored. 
> It needs to be answered.
> 
> Is Avalon for ANY other purpose than *Component Re-Use* or not? That is 
> certainly my only interest. It is arguably what attracts most people to 
> it? True or false?
> 
> If it is, then Berin's excellent viewpoints on simplicity and ease of 
> use may still be valid, and it seems much more likely that an easy to 
> learn, easy to code version of Avalon is still quite possible, or at 
> least that a ratched complexity model of behaviour is attainable.
> 
> If not, then what other purposes does Avalon serve? For example, if a 
> component was NOT going to be re-used on another project, is there any 
> reason whatsoever to Avalon it or should it just be instantiated as any 
> other OO object ? Is Avalon then becoming complex and difficult to learn 
> and use because of the inherently complex objectives, or is because it's 
> objectives aren't clear, so a shotgun approach is required to make sure 
> that every avenue is accounted for? What a nightmare.
> 
> Without a very clear objective, solving it keeps appearing to be 
> possible, but then evaporates as the details are discussed, not because 
> of the details themselves, but because the participants are trying to 
> solve different problems. It's a pot of gold at the end of a rainbow - 
> closer you get..... Hence Stefano's commentary on Cocoon using Avalon 
> where it shouldn't be used in the first place.
> 
> Mark Shepard, a suit from TI was credited with the saying that "More 
> than two objectives is no objectives at all".
> 
> If you don't know where you are going, any road will get you there. 
> Someone else said that.
> 
> *Component Re-Use*. Is that the only objective or not? True or False. 
> Make your stand now, and then stick to it.
> 
> Not fair to cite SoC or IoC or Separation of Interface and 
> Implementation. They still make sense, but only because the objective is 
> assumed as common sense.
> 
> 
> 
> 
> 
> 
> -- 
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
> 


-- 
<Mike/>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Make your stand now - Is Avalon for more than ReUse ?

[Peter Donald <pe...@apache.org>]

At 10:29 PM 6/22/2002 -0400, you wrote:
> > Anyone can make something awkward and complex. It is true art to make it
> > simple again. (don't look at me, I'm no artist either.).
>
>To draw inspiration from the French writer Antoine de Saint-Exupery:
>
>   La perfection est atteinte non quand il ne reste rien a ajouter,
>   mais quand il ne reste rien a enlever.
>
>   Perfection is achieved, not when there is nothing more to add,
>   but when there is nothing left to take away.


I like. I do believe I just aquired a new email sig ;)


Cheers,

Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
              - John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Make your stand now - Is Avalon for more than ReUse ?

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

> From: Leo Simons [mailto:leosimons@apache.org] 
> 
> The core framework Avalon promotes and facilitates is 
> appropriate wherever you write java software. It would also 
> be appropriate in C#,
> C++ (if it were feasible, which it is probably not).

It is feasible, but it is also more difficult.  You have to worry
about shared library support, name mangling, etc.  The way out
of the Interface issue is to use pure virtual classes.  There are
other sticking points, but they are resolvable.

One thing that C++ has going for it is algorithmic programming
(templates/generics), which Java does not do well at all.

However, that is neither here nor there.  You do need a modern
C++ compiler with proper support for Exceptions and RunTime Type
Identification (RTTI).



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Make your stand now - Is Avalon for more than ReUse ?

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

On Fri, 2002-06-21 at 00:08, Pete Carapetyan wrote:
> >>What are the objectives, if they are more than re-use? Can you identify 
> >>them?
> >>    
> >>
> >
> >stuff like:
> >
> >- clean code
> >- common program flow in code
> >- instant well-designed architecture
> >- speed
> >
> True, but hardly unique to the goals of Avalon. These are goals of any 
> good software. Non COP coders claim these objectives as well, and the 
> 2nd and 3rd are also attributes of Re-Use as well as mutually exclusive 
> objectives.

the difference: we accomplish them better ;)

> Berin is on the money. The use cases are the key. What are the use cases 
> for Avalon? What are use cases where Avalon is not appropriate? What is 
> the common thread for each.

The core framework Avalon promotes and facilitates is appropriate
wherever you write java software. It would also be appropriate in C#,
C++ (if it were feasible, which it is probably not).

AspectJ has gone down the route of providing an extension to the core
java language. Avalon could have been implemented that way as well;
which we haven't done for obvious reasons.

use cases for avalon framework: any software
use cases for avalon excalibur: any server-like software
use cases for avalon phoenix: server software, server software
frameworks
use cases for avalon fortress: server software

Hence the extreme difficulty in coming up with the framework interfaces
and contracts. All use cases are valid, the only thing that can be bad
is how to satisfy the use cases.

Only when you talk about more specific bits than you are hinting at (for
example, valid use cases for the Composable interface), can a little
more concrete discussion take place.

regards,

- Leo



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Make your stand now - Is Avalon for more than ReUse ?

["Gonzalo A. Diethelm" <go...@vtr.net>]

> Anyone can make something awkward and complex. It is true art to make it 
> simple again. (don't look at me, I'm no artist either.).

To draw inspiration from the French writer Antoine de Saint-Exupery:

  La perfection est atteinte non quand il ne reste rien a ajouter,
  mais quand il ne reste rien a enlever.

  Perfection is achieved, not when there is nothing more to add,
  but when there is nothing left to take away.


-- 
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Make your stand now - Is Avalon for more than ReUse ?

[Pete Carapetyan <pe...@datafundamentals.com>]

Leo Simons wrote:

>>What are the objectives, if they are more than re-use? Can you identify 
>>them?
>>    
>>
>
>stuff like:
>
>- clean code
>- common program flow in code
>- instant well-designed architecture
>- speed
>
True, but hardly unique to the goals of Avalon. These are goals of any 
good software. Non COP coders claim these objectives as well, and the 
2nd and 3rd are also attributes of Re-Use as well as mutually exclusive 
objectives.

><snip/>
>
>What you ask thus is "what are the objects of software architecture
>design?" and "what are the benefits of component libraries?" The answers
>are all over the place; many apply to avalon.
>
I guess I keep trying to differentiate between atttributes of good 
design, and specific objectives that differentiate the Avalon Framework 
from OO design. Most of these things, including all the patterns in use 
throughout the industry are all fantastic patterns and Avalon should 
have them too, as great attributes. But they are not the primary unique 
objective, as can be observed by viewing the defined by use cases, and 
by the fact that they apply equally to straight OO as to Avalon, which 
is anything but straight OO.

Berin is on the money. The use cases are the key. What are the use cases 
for Avalon? What are use cases where Avalon is not appropriate? What is 
the common thread for each.

If Peter Donald says that xxx is a stupid thing, and Stefano says yeah, 
that was pretty stupid, I agree, and he was the only one using xxxx, 
then it is a bad use case and attempting to accomodate it into the 
pattern at the expense of making the entire framework un-necessarily 
complex is pretty stupid. At least from that viewpoint. So you dumb it 
back down and quit trying to do something that is not the primary 
objective anyway. Seems something that Spock would +1 for.

Simplification is not just a silly excercise, because what Berin has 
vocalized very well is the possibility for clean, well articulated 
design that can be adopted by less than geniuses. It may piss the 
geniuses off, they may want to be the only ones who understand it, but 
that's not the goal. What has been said here about "pretty soon it 
becomes another whole language unto itself" is true. The geniuses may 
not want to let their baby out of the lab. So be it. The goal is to get 
it down to the essence. Then add each complexity only as needed, and in 
direct relation to each value gained. Surely that is a doable deal.

Doesn't mean there would be plenty of chances for fun arguments and lots 
of brandishing of very fancy swordsmanship. It is a belief that the 
framework can be reduced to it's essence first, and made understandable 
and syntactically secure, and then the swordsmanship can happen at the 
edges where it doesn't keep the core of A5 from the 99% of programmers 
who would love to share components if it were reduced to it's essence 
first, but won't because it isn't yet.

Anyone can make something awkward and complex. It is true art to make it 
simple again. (don't look at me, I'm no artist either.).

I've said it before. I'll say it again. Current Avalon developers have 
much much more of a cool thing here than they appear to grok. If you can 
make the move that Berin has hinted at, it could be a lot of fun for 
more than just you, and not at your expense either. But someone has to 
want it. I guess that would have to include me, because I would like to 
see this thing settle down into that very place. It can be done.

Re: Make your stand now - Is Avalon for more than ReUse ?

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

> What are the objectives, if they are more than re-use? Can you identify 
> them?

stuff like:

- clean code
- common program flow in code
- instant well-designed architecture
- speed

etc etc. I doesn't matter that much to me whether you reuse stuff I
write at all. I care about well-designed software. Reuse is an added
benefit.

The benefits of using avalon are partially the same as those of reuse,
RAD, etc. Partially, they are the same as those of Design Patterns.

Basically, avalon is about (a common) java server software architecture
(like all frameworks are about defining a common architecture) on the
one hand, and about providing specific parts of that server architecture
on the other hand (like all component libraries).

What you ask thus is "what are the objects of software architecture
design?" and "what are the benefits of component libraries?" The answers
are all over the place; many apply to avalon.

- Leo Simons



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Make your stand now - Is Avalon for more than ReUse ?

[Stephen McConnell <mc...@osm.net>]

Nicola Ken Barozzi wrote:

>
>
> Pete Carapetyan wrote:
>
>> Leo Simons wrote:
>>
>>>> Not fair to cite SoC or IoC or Separation of Interface and 
>>>> Implementation. They still make sense, but only because the 
>>>> objective is assumed as common sense.
>>>>   
>>>
>>>
>>>
>>> that's your stance on it.
>>>  
>>>
>> Not much of a stance, as stance implies that I believe in what I am 
>> saying. More like a tentative viewpoint looking for opposing 
>> clarifications.
>>
>> I must an attempt to separate what from how. I get lost in the how, 
>> fried my brain in a previous life. So now I have to be very careful 
>> to separate what from how, otherwise I get stuck in how and lose 
>> track of what. Happens to others also, I've noticed.
>>
>> Berin is right on. He keeps trying to bring it back to the use cases. 
>> They all seem like re-use to me. But my handicap has already been 
>> identified, maybe brighter folks can point out other objectives than 
>> I am seeing.
>>
>> What are the objectives, if they are more than re-use? Can you 
>> identify them?
>
>
> Avalon is an API that, correctly implemented and used, makes better, 
> cleaner, easier and more manageable software.
>
> -Better: it enforces good programming practices: IOC, SOC, etc---
> -Cleaner: COP
> -Easier: intuitive and clean APIS
> -Manageable: Component-Container
>
> It has reference implementation of components that help implement it 
> (Excalibur), and a reference implementation of a server (since we're 
> at Apache, let's not forget it ;-)
>
> I started using Avalon API in an app of mine that din't use it at 
> first, and in 2 days I found myself, without understanding really why, 
> with a really cool system. The API really enforced good practices!
>
> The power of Avalon is in the API.
> That's why we fight (we are knights) over the API, rarely over the 
> implementations.
>
+1
You can post this!

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Make your stand now - Is Avalon for more than ReUse ?

[Nicola Ken Barozzi <ni...@apache.org>]

Pete Carapetyan wrote:
> Leo Simons wrote:
> 
>>> Not fair to cite SoC or IoC or Separation of Interface and 
>>> Implementation. They still make sense, but only because the objective 
>>> is assumed as common sense.
>>>   
>>
>>
>> that's your stance on it.
>>  
>>
> Not much of a stance, as stance implies that I believe in what I am 
> saying. More like a tentative viewpoint looking for opposing 
> clarifications.
> 
> I must an attempt to separate what from how. I get lost in the how, 
> fried my brain in a previous life. So now I have to be very careful to 
> separate what from how, otherwise I get stuck in how and lose track of 
> what. Happens to others also, I've noticed.
> 
> Berin is right on. He keeps trying to bring it back to the use cases. 
> They all seem like re-use to me. But my handicap has already been 
> identified, maybe brighter folks can point out other objectives than I 
> am seeing.
> 
> What are the objectives, if they are more than re-use? Can you identify 
> them?

Avalon is an API that, correctly implemented and used, makes better, 
cleaner, easier and more manageable software.

-Better: it enforces good programming practices: IOC, SOC, etc---
-Cleaner: COP
-Easier: intuitive and clean APIS
-Manageable: Component-Container

It has reference implementation of components that help implement it 
(Excalibur), and a reference implementation of a server (since we're at 
Apache, let's not forget it ;-)

I started using Avalon API in an app of mine that din't use it at first, 
and in 2 days I found myself, without understanding really why, with a 
really cool system. The API really enforced good practices!

The power of Avalon is in the API.
That's why we fight (we are knights) over the API, rarely over the 
implementations.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Make your stand now - Is Avalon for more than ReUse ?

[Pete Carapetyan <pe...@datafundamentals.com>]

Leo Simons wrote:

>>Not fair to cite SoC or IoC or Separation of Interface and 
>>Implementation. They still make sense, but only because the objective is 
>>assumed as common sense.
>>    
>>
>
>that's your stance on it.
>  
>
Not much of a stance, as stance implies that I believe in what I am 
saying. More like a tentative viewpoint looking for opposing 
clarifications.

I must an attempt to separate what from how. I get lost in the how, 
fried my brain in a previous life. So now I have to be very careful to 
separate what from how, otherwise I get stuck in how and lose track of 
what. Happens to others also, I've noticed.

Berin is right on. He keeps trying to bring it back to the use cases. 
They all seem like re-use to me. But my handicap has already been 
identified, maybe brighter folks can point out other objectives than I 
am seeing.

What are the objectives, if they are more than re-use? Can you identify 
them?

Re: Make your stand now - Is Avalon for more than ReUse ?

[Leo Simons <ls...@multimia.com>]

> Is Avalon for ANY other purpose than *Component Re-Use* or not?

yes!

Avalon Framework: facilitate COP by promoting some very good patterns
and meta patterns

Avalon Excalibur: provide reusable components

Avalon Phoenix: run reusable components and services, decorate them with
extra security, facilitate multiple applications running in a the same
VM, IOW: general server kernel

etc etc. All this is in the docs.

> *Component Re-Use*. Is that the only objective or not? True or False. 
> Make your stand now, and then stick to it.

False. See docs, see charter.

> Not fair to cite SoC or IoC or Separation of Interface and 
> Implementation. They still make sense, but only because the objective is 
> assumed as common sense.

that's your stance on it.

cheers,

- Leo



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Make your stand now - Is Avalon for more than ReUse ?

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

> From: Pete Carapetyan [mailto:pete@datafundamentals.com] 
> 
> Is Avalon for ANY other purpose than *Component Re-Use* or 
> not?

Yes.

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Make your stand now - Is Avalon for more than ReUse ?

[Pete Carapetyan <pe...@datafundamentals.com>]

Submitted this question within <flamebait/> earlier, but it got ignored. 
It needs to be answered.

Is Avalon for ANY other purpose than *Component Re-Use* or not? That is 
certainly my only interest. It is arguably what attracts most people to 
it? True or false?

If it is, then Berin's excellent viewpoints on simplicity and ease of 
use may still be valid, and it seems much more likely that an easy to 
learn, easy to code version of Avalon is still quite possible, or at 
least that a ratched complexity model of behaviour is attainable.

If not, then what other purposes does Avalon serve? For example, if a 
component was NOT going to be re-used on another project, is there any 
reason whatsoever to Avalon it or should it just be instantiated as any 
other OO object ? Is Avalon then becoming complex and difficult to learn 
and use because of the inherently complex objectives, or is because it's 
objectives aren't clear, so a shotgun approach is required to make sure 
that every avenue is accounted for? What a nightmare.

Without a very clear objective, solving it keeps appearing to be 
possible, but then evaporates as the details are discussed, not because 
of the details themselves, but because the participants are trying to 
solve different problems. It's a pot of gold at the end of a rainbow - 
closer you get..... Hence Stefano's commentary on Cocoon using Avalon 
where it shouldn't be used in the first place.

Mark Shepard, a suit from TI was credited with the saying that "More 
than two objectives is no objectives at all".

If you don't know where you are going, any road will get you there. 
Someone else said that.

*Component Re-Use*. Is that the only objective or not? True or False. 
Make your stand now, and then stick to it.

Not fair to cite SoC or IoC or Separation of Interface and 
Implementation. They still make sense, but only because the objective is 
assumed as common sense.






--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Fake parade--NOT!

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

> From: Stephen McConnell [mailto:mcconnell@osm.net] 
> 
> This is the framework reference implementation of release.  
> Yes - it is 
> easy to understand, yes - its easy to use.  Could we come up with 
> something that is better? Yes - remove it and delivery 
> something better 
> in the right level of abstraction.  But the big point is that 
> your email 
> is making assertions that are only rational if your understanding of 
> Avalon Framework is Avalon Framework + ECM conventions and 
> implementation.


+ Fortress.

The ECM is used by a great many of our users.  There is a smooth
(or relatively smooth) migration from ECM to Fortress.  There are
also benefits that Fortress provides which ECM doen't such as
higher scalability due to offloading management functions into
asynchronous functions.

However, I haven't *removed* existing functionality.

If we ignore our existing users we will piss them off royally.
We need to think of them.

Another important thing is that assumptions held by a large number
of people (which include many of our users) in themselves become
contracts.  To ignore that fact because we didn't explicitly
state the contract is really bad.

I have been working at the possibility of removing pooled support
for a while now.  There are simply some ways that the ECM/Fortress
is used that doesn't permit that yet.

We are getting closer, but you can't remove expected functionality
without providing a better substitute--which is what we are doing
if we remove the release() method at this time.

The fact is, ECM, Fortress, Merlin, and Phoenix all implement the
contracts as they are laid out for containers at this moment.
However, they are only *partially* compatible.  We need you and
Peter to finish the meta-data so that they can be even more
compatible.  Fortress will follow suite, and ECM will die.

There are things that I need to explore with Fortress that may
provide a better solution to explicit pooling, making it impossibly
easy to create threadsafe components.  Until they exist, the
release() method needs to stay.  Which is why I am suggesting
to temporarily table A5.


> >> It is
> >>simply
> >>the ratraction of an abstact operation that cannot be 
> >>supported at the framework's level.  Nothing more - nothing 
> >>less. I'm not promoting or 
> >>opposing
> >>that position here - what I am doing is directly challenging 
> >>the the assumptions you are implying about A4 and its 
> >>evolution.  In reality, this email is a fake parade that 
> >>argues for the value of something we don't have.  
> >>
> >
> >I don't get the fake parade thing at all.
> >
> 
> Too much implied in beteen the lines. Positioning the containerkit as 
> overly complex - why - have you used it - have your tried to develop 
> something with it?  I have - it is simple to use - took no 
> more that a 
> couple of days to get something operation in place.  Containerkit is 
> simple - what's not simple is what containerkit implies.  But 
> the iussue 
> here is that containkit is implying the defintion of what a component 
> really is - and that is much more of a concrete issue.  My 
> fake-parade 
> comment is specifically addressing the issue of "lets ignore whats 
> really happenning" - "lets imagine that what we have is 
> perfect" - what 
> we have today is really great - but when we are discussing 
> evolution and 
> forward looking development - we cannot - must not - ignore our 
> functional limitations (e.g. the amazingly complex release 
> operation imp 
> described above - or the responsibilities we have when 
> defining what a 
> component really is).


Restating my *intended* message:

Let's not hide a complex problem with software if there is a simpler
approach.

I assert that J2EE's ServiceManager concept is flawed because it is
an additional layer overtop a monster that Sun has created.  Instead
of fixing the underlying problems associated with resolving EJBs and
other J2EE components, they add another software layer overtop.  Even
more specious is the fact that they expect every company to develop
the same fundamental solution themselves instead of providing the
abstraction.

Let's simplify as much as possible, and then use the software to make
it dirt easy.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Fake parade--NOT!

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

> From: Stephen McConnell [mailto:mcconnell@osm.net] 
> Berin Loritsch wrote:
> 
> Ok, lets take the DefaultComponentManager.release() operation - the 
> implementation currently is the following:
> 
>     public void release( final Component component )
>     {
>     }
> 
> This is the framework reference implementation of release.  
> Yes - it is 
> easy to understand, yes - its easy to use.

(Just noticed: It is dead wrong as well. The dispose() method is 
 not called for SingleThreaded components.)

> Could we come up with something that is better?
> Yes - remove it and delivery something better in 
> the right level of abstraction. 

Well, what would that be? 

If you claim to want a grounded debate, then for the love of God,
can you come up with something better that *is* at the right level
of abstraction and at the same time *is* easy for our users?

All proposals so far to that effect have either been:

 1) not workable

 2) pushing way too much responsibility on to 
    the component writer

 3) too complex to be understood

You can argue that "easy" means "just like ECM" and you'd be
partially right. But whether your reference point is ECM or not,
ECM has some very good features that many people have found useful
and that would be removed if release() is removed.

You can argue for removal of those features from the framework, 
but then I'd like you to give me a replacement for those features.

I'm with Berin on this one.

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Fake parade--NOT!

[Stephen McConnell <mc...@osm.net>]

Berin Loritsch wrote:

>>From: Stephen McConnell [mailto:mcconnell@osm.net] 
>>
>>Freedom is not being removed.  Let get that strait. Assume 
>>for the purpose of this discourse that a framework is 
>>released without "remove".
>>
>
>My point being that such an operation should not be taken
>without providing an alternative solution that is
>
>1) better
>2) easier to use
>

Ok, lets take the DefaultComponentManager.release() operation - the 
implementation currently is the following:

    public void release( final Component component )
    {
    }

This is the framework reference implementation of release.  Yes - it is 
easy to understand, yes - its easy to use.  Could we come up with 
something that is better? Yes - remove it and delivery something better 
in the right level of abstraction.  But the big point is that your email 
is making assertions that are only rational if your understanding of 
Avalon Framework is Avalon Framework + ECM conventions and implementation.

>
>> It is 
>>simply
>>the ratraction of an abstact operation that cannot be 
>>supported at the framework's level.  Nothing more - nothing 
>>less. I'm not promoting or 
>>opposing
>>that position here - what I am doing is directly challenging 
>>the the assumptions you are implying about A4 and its 
>>evolution.  In reality, this email is a fake parade that 
>>argues for the value of something we don't have.  
>>
>
>I don't get the fake parade thing at all.
>

Too much implied in beteen the lines. Positioning the containerkit as 
overly complex - why - have you used it - have your tried to develop 
something with it?  I have - it is simple to use - took no more that a 
couple of days to get something operation in place.  Containerkit is 
simple - what's not simple is what containerkit implies.  But the iussue 
here is that containkit is implying the defintion of what a component 
really is - and that is much more of a concrete issue.  My fake-parade 
comment is specifically addressing the issue of "lets ignore whats 
really happenning" - "lets imagine that what we have is perfect" - what 
we have today is really great - but when we are discussing evolution and 
forward looking development - we cannot - must not - ignore our 
functional limitations (e.g. the amazingly complex release operation imp 
described above - or the responsibilities we have when defining what a 
component really is).

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Fake parade--NOT!

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

> From: Stephen McConnell [mailto:mcconnell@osm.net] 
> 
> Freedom is not being removed.  Let get that strait. Assume 
> for the purpose of this discourse that a framework is 
> released without "remove".

My point being that such an operation should not be taken
without providing an alternative solution that is

1) better
2) easier to use

>  It is 
> simply
> the ratraction of an abstact operation that cannot be 
> supported at the framework's level.  Nothing more - nothing 
> less. I'm not promoting or 
> opposing
> that position here - what I am doing is directly challenging 
> the the assumptions you are implying about A4 and its 
> evolution.  In reality, this email is a fake parade that 
> argues for the value of something we don't have.  

I don't get the fake parade thing at all.


Stephen, the removal of ComponentSelector and the need for
a lookup(name, hint) is possible with the addition of the
meta info.  The meta info resolution is an entriguing idea.

I want to go forward with that idea.  However, I want to keep
an eye on complexity--both on the container's side and on the
component/client's side.

Any move that would require more work for the client is a
*bad* move.  Hense the XXXXManager solution proposed a while
back would be a *bad* move.

Do not remove a feature without providing a solid replacement.
That will help the discussions from getting stuck on "sacred
cows" which has repeatedly happening.

Too much PFM, and people get nervous (does it really do it
*every* time?).  BTW, PFM = Pure F***ing Magic.  Not enough
and people get aggitated (you mean I have to do this again
and again?).

We have to strike the balance.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: www.amiafakeparadeornot.com (was: RE: Fake parade)

[Paulo Gaspar <pa...@krankikom.de>]

"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
=;o)

Paulo

> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Friday, June 21, 2002 2:19 AM
> To: Avalon Developers List
> Subject: Re: www.amiafakeparadeornot.com (was: RE: Fake parade)
> 
> 
> At 09:57 PM 6/20/2002 +0200, you wrote:
> >It is not the case that removal of release() only impacts framework.
> >In fact, I think we have reached the conclusion that *no*
> >*container-managed* pooling of components is possible without
> >release().
> 
> Release at end of scope can be done by container or by user of resource 
> doing a close() on resource.  Though I do believe I may have said this a 
> few times in the past.
> 
> 
> Cheers,
> 
> Peter Donald
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Faced with the choice between changing one's mind,
> and proving that there is no need to do so - almost
> everyone gets busy on the proof."
>               - John Kenneth Galbraith
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> --
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
> 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: www.amiafakeparadeornot.com (was: RE: Fake parade)

[Peter Donald <pe...@apache.org>]

At 09:57 PM 6/20/2002 +0200, you wrote:
>It is not the case that removal of release() only impacts framework.
>In fact, I think we have reached the conclusion that *no*
>*container-managed* pooling of components is possible without
>release().

Release at end of scope can be done by container or by user of resource 
doing a close() on resource.  Though I do believe I may have said this a 
few times in the past.


Cheers,

Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
              - John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Fake parade

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

> From: Stephen McConnell [mailto:mcconnell@osm.net] 
> 
> I'm arguming aginst what is implied in Berlin's post: 
> Implications of the post are:
> 
>   1. assertion that containerkit is overly complex (which I
>      happen to completely disagree with) when the real issue
>      is the implications this has on concretly defining a
>      component - emotive words are used in the post that bypass
>      the real question


Not what I was trying to convey.  The message I was trying to
convey is let's not use a toolkit to hide a more complext
problem if we can avoid the complexity altogether.

It is like J2EE's addition of the ServiceLocator interface.  It's
purpose is to abstract away all calls to the JNDI interface, provide
client side caching of the remote object handles, etc.

The underlying problem is in the way JNDI is used, adding the extra
layer merely hides that fact.

My assertion was that covering a complex solution with a simple
interface isn't always the better choice.  If there is a less
complex solution, we should use it.



>   2. discussing the merits of thread safety in A5 when in fact
>      the framework does not concretely support this - kernals
>      and containers above framework do this but the assertion
>      is being made that this is a framework issue - it is in
>      terms of future development - but this is in terms of
>      delivering something concrete that does not exist in the
>      framework today


Avalon Framework as it stands does not make any claims to support
more than one thread.  However, we know it would be quite useless
if it didn't.  Esp. when it is used on the server.

The fact that A4 has the release() method to return pooled components
to the container implies that this is a correct practice.  However,
the resolutions of this issue have not been satisfactory yet.  We
know we want to remove it, but we need to come up with a workable
solution so that migration from A4 to A5 for components that assume
this behavior will have the least amount of work to do.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: www.amiafakeparadeornot.com (was: RE: Fake parade)

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

On Thursday 20 June 2002 03:57 pm, Leo Sutic wrote:
> I'm off for midsummer's now, so I might not be able to reply to anything
> until Saturday. The only thing that has to do with this discussion is
> that
> I might come in contact with pools of liquor and herring, and that
> too much of that will cause my heart to be stop()'ed, my body put
> in a container (coffin) and dispose()'d, all of this before I even
> considered myself start()'ed.

you're reinitializable(), right?

have fun :)
-pete

-- 
peter royal -> proyal@apache.org

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

[OT] Re: www.amiafakeparadeornot.com (was: RE: Fake parade)

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

> I'm off for midsummer's now, so I might not be able to reply to anything
> until Saturday. The only thing that has to do with this discussion is
> that
> I might come in contact with pools of liquor and herring, and that
> too much of that will cause my heart to be stop()'ed, my body put
> in a container (coffin) and dispose()'d, all of this before I even
> considered myself start()'ed.
> 
> (Yes yes I'll shut up and go now.)

hey, there's some bad architecture that specifies a non-optional
dependency on a specific Leo.S.-implementation!!! Be sure to get back!

have fun :D

- non-dependency-satisfying Leo S



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: www.amiafakeparadeornot.com (was: RE: Fake parade)

[Stephen McConnell <mc...@osm.net>]

Leo Sutic wrote:

>  
>
>>From: Stephen McConnell [mailto:mcconnell@osm.net] 
>>
>>  2. discussing the merits of thread safety in A5 when in fact
>>     the framework does not concretely support this - kernals
>>     and containers above framework do this but the assertion
>>     is being made that this is a framework issue - it is in
>>     terms of future development - but this is in terms of
>>     delivering something concrete that does not exist in the
>>     framework today
>>    
>>
>
>What he is arguing is, I think, that the explicit removal of support
>for some things in the framework would have bad effects on containers
>and kernels.
>
>The contracts the ECM has with its components may not have a basis in
>the framework - for example, the Poolable interface is nowhere to be 
>found in Avalon/Framework, and you can thus argue that ECM 
>overpromised and that there is no need to honor that contract
>when discussing framework issues, but that contract, that promise 
>of the ECM to pool components *can not* be kept if you remove
>release() from the framework.
>
>It is not the case that removal of release() only impacts framework.
>In fact, I think we have reached the conclusion that *no* 
>*container-managed* pooling of components is possible without 
>release().
>
>At the same time, this container-managed pooling is something that
>people have found very useful.
>
>So I do not think you can neatly classify things into framework and 
>non-framework issues, without thinking about how the framework issues
>impact the non-framework issues.
>  
>

Leo:

You have got the point of my concerns. But let me go a little step
further and say that we have come a long way in understanding what
aspects of the framework impact tools and applications above the
framework - and this is leading to better understanding of what changes
/evolution etc. is needed in the framework to reduce client code while
maintaining portability.

>I understand that you argue against the "ECM is the only true reference
>container" approach seen sometimes. But your argument is also 
>against container-managed pooling. 
>

Not at all.  I would really like to see the pooling question resolved
(I'm not ignoring you last email to me on that point).  For me the issue
are closely linked to the approaches the framework enables for fundimental
extension.

>And that means decreased usability.
>And I'm against that.
>

Me to.  

>
>/LS
>
>I'm off for midsummer's now, so I might not be able to reply to anything
>until Saturday. The only thing that has to do with this discussion is
>that
>I might come in contact with pools of liquor and herring, and that
>too much of that will cause my heart to be stop()'ed, my body put
>in a container (coffin) and dispose()'d, all of this before I even
>considered myself start()'ed.
>

What, no release( leo )
LOL - wish I was doing the same thing!

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

www.amiafakeparadeornot.com (was: RE: Fake parade)

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

> From: Stephen McConnell [mailto:mcconnell@osm.net] 
>
>   2. discussing the merits of thread safety in A5 when in fact
>      the framework does not concretely support this - kernals
>      and containers above framework do this but the assertion
>      is being made that this is a framework issue - it is in
>      terms of future development - but this is in terms of
>      delivering something concrete that does not exist in the
>      framework today

What he is arguing is, I think, that the explicit removal of support
for some things in the framework would have bad effects on containers
and kernels.

The contracts the ECM has with its components may not have a basis in
the
framework - for example, the Poolable interface is nowhere to be found
in Avalon/Framework, and you can thus argue that ECM overpromised and
that
there is no need to honor that contract when discussing framework
issues,
but that contract, that promise of the ECM to pool components *can not*
be kept if you remove release() from the framework.

It is not the case that removal of release() only impacts framework.
In fact, I think we have reached the conclusion that *no* 
*container-managed* pooling of components is possible without 
release().

At the same time, this container-managed pooling is something that
people have found very useful.

So I do not think you can neatly classify things into framework and 
non-framework issues, without thinking about how the framework issues
impact the non-framework issues.

I understand that you argue against the "ECM is the only true reference
container" approach seen sometimes. But your argument is also 
against container-managed pooling. And that means decreased usability.
And I'm against that.

/LS

I'm off for midsummer's now, so I might not be able to reply to anything
until Saturday. The only thing that has to do with this discussion is
that
I might come in contact with pools of liquor and herring, and that
too much of that will cause my heart to be stop()'ed, my body put
in a container (coffin) and dispose()'d, all of this before I even
considered myself start()'ed.

(Yes yes I'll shut up and go now.)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Fake parade

[Stephen McConnell <mc...@osm.net>]

Leo Sutic wrote:

>Stephen,
>
>are you arguing against the use of the word "freedom" in this
>context, or against something else?
>
>That is, would you remove your -1 if "freedom" was replaced with
>another word, say "features"?
>
>I do not quite follow you...
>

I'm arguming aginst what is implied in Berlin's post:
Implications of the post are:

  1. assertion that containerkit is overly complex (which I
     happen to completely disagree with) when the real issue
     is the implications this has on concretly defining a
     component - emotive words are used in the post that bypass
     the real question

  2. discussing the merits of thread safety in A5 when in fact
     the framework does not concretely support this - kernals
     and containers above framework do this but the assertion
     is being made that this is a framework issue - it is in
     terms of future development - but this is in terms of
     delivering something concrete that does not exist in the
     framework today

Cheers, Steve.

>
>
>/LS
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Fake parade

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

Stephen,

are you arguing against the use of the word "freedom" in this
context, or against something else?

That is, would you remove your -1 if "freedom" was replaced with
another word, say "features"?

I do not quite follow you...

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Fake parade

[Stephen McConnell <mc...@osm.net>]

Freedom is not being removed.  Let get that strait. Assume for the purpose
of this discourse that a framework is released without "remove".  It is 
simply
the ratraction of an abstact operation that cannot be supported at the
framework's level.  Nothing more - nothing less. I'm not promoting or 
opposing
that position here - what I am doing is directly challenging the the
assumptions you are implying about A4 and its evolution.  In reality, this
email is a fake parade that argues for the value of something we don't
have.  

Please - please - please - lets keep the discussion grounded.

Cheers, Steve.


Berin Loritsch wrote:

>In my experiences with computing, the company's motto that impressed me
>the most was Be, Inc.  Jean Louis Gasse' (sp?) was a genious for
>promoting
>the mindset of "Under Promise, Over Deliver".  For a commercial company
>it really hampers the marketing department, but for an OSS project it is
>the only mindset to have.
>
>There are some key obstacles that seem to be in our way of achieving
>this goal:
>
>1) Over design, under simplification
>2) Big ego, small content
>
>The big ego, small content has already been hammered on, so we will try
>to keep the signal to noise ratio down.
>
>So far the most productive thread we have had was the "Fresh
>Perspective",
>as I finally got what Stephen and Peter were pushing (although at first
>it was just Stephen).  There is a lot to like in it.
>
>Our biggest problem is Over Design, Under Simplification.  The job of a
>*usable* framework is to enable things to be done that otherwise could
>not be done.  Avalon 4 does this quite well.  There are some things that
>does not sit well with me in the track we are on for A5.  They are
>listed
>below:
>
>1) The container specification is becoming quite complex.  The
>complexity
>   is hoped to be made up for by a "ContainerKit", but if someone wanted
>   to discard the container kit and create their own container from
>scratch
>   it is approaching the level of needing a company to finance the
>   proposition.  This is not good.
>
>2) We are pushing *more* of the burden of design, thread safety issues,
>   etc. on the component developer.  This is a *bad* choice.  ColdFusion
>   4 tried to automatically handle the locking of CF script variables,
>   but did a poor job of it.  Their solution was to offload that
>   responsibility to the page developers.  By CF 4.5, we had a product
>that
>   needed to be revamped to explicitly handle locking of variables.  We
>   are making the same mistake regarding pooling of components.
>
>3) If anything, we want to make it *easier* to use.  Even better we want
>   to make it *easier* to use correctly.  While it is a design goal to
>   encourage good practices and discourage bad practices, we can't all
>   do that at the interface level.  People follow examples, good or bad.
>
>Now documentation and examples are something we can do in A4.  However
>it
>is the type of examples that need to make sense.  We need to demonstrate
>*why* something is bad (performance, maintenance, scalability, etc.),
>and
>how to correct it *easily*.  Something like the J2EE BluePrint document
>would be best.  We need to demonstrate how certain designs just work
>better,
>and aren't that much more difficult to do.
>
>Some things are difficult to do.  Pooling components is a valid
>proposition.
>You could have fewer instances of components than threads of execution
>(as
>opposed to the more common case in Cocoon where there are multiple
>instances per thread of execution).  However, removing the release()
>method
>has incredible consequences on existing code for only a little ease in
>the container.
>
>As Benjamin Franklin said, "They that give up essential liberty to
>obtain a
>little temporary safety deserve neither liberty nor safety."  While
>it has more to do with patriotism than with development, it still
>applies.
>
>Unless we provide a fundamentally *better* approach that does not tax
>our
>users, the proposed approach is flawed.  It is like when England raised
>taxes on American soil without giving them representation in parliament.
>The Americans eventually revolted, casting all things English aside.  It
>wasn't until much later that America and England could stand each other
>enough to resume trade relations.
>
>This is *not* what we want for Avalon.  Any freedom we remove *must*
>be replaced with something better.
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Under Promise, Over Deliver

[Nicola Ken Barozzi <ni...@apache.org>]

[EDITED]

Stephen McConnell wrote:
> 
> Nicola Ken Barozzi wrote:
> 
>> Berin Loritsch and Nicola Ken Barozzi wrote:
>>
>>> In my experiences with computing, the company's motto that impressed me
>>> the most was Be, Inc.  Jean Louis Gasse' (sp?) was a genious for
>>> promoting
>>> the mindset of "Under Promise, Over Deliver".  For a commercial company
>>> it really hampers the marketing department, but for an OS project it is
>>> the only mindset to have.
>>>
>>> There are some key obstacles that can be in the way of achieving
>>> this goal, for any project:
>>>
>>> 1) Over design, under simplification
>>> 2) Big ego, small content
>>>
>>> The big ego, small content is typical of OS, and the community should 
>>> always remember to keep the signal to noise ratio down.
>>>
>>> When discussion is overheating, remember the golden rule:
 >>> write a mail, give it all you've got, then reread it and delete it.
 >>> Start over, any finally try to get your point through, if you
 >>> still have a point, that is.
>>>
>>> Another problem is Over Design, Under Simplification.  The job of a
>>> *usable* framework is to enable things to be done that otherwise could
>>> not be done.  Avalon 4 does this quite well, and it's our committment
 >>> to make it ever better.
>>>
>>> 1) Some specifications can becoming quite complex.  
>>>    The complexity sometimes can be reduced by creating a better set
 >>>    of helper classes or implementation
 >>>    Acid test: If someone wanted
>>>    to discard the new  kit and create their own from scratch
>>>    it would be approaching the level of needing a company to 
 >>>    finance the proposition.  This is not good.
>>>
>>> 2) Pushing *more* of the burden of design, thread safety issues,
>>>    etc. on the component developer?  This is a *bad* choice.  ColdFusion
>>>    4 tried to automatically handle the locking of CF script variables,
>>>    but did a poor job of it.  Their solution was to offload that
>>>    responsibility to the page developers.  By CF 4.5, we had a product
>>>    that
>>>    needed to be revamped to explicitly handle locking of variables.
>>>
>>> 3) If anything, we want to make it *easier* to use.  Even better we want
>>>    to make it *easier* to use /correctly/.  While it is a design goal to
>>>    encourage good practices and discourage bad practices, we can't all
>>>    do that at the interface level.  People follow examples, good or bad.
>>>
>>> Now documentation and examples are something we must always do. However
>>> it
>>> is the type of examples that need to make sense.  We need to demonstrate
>>> *why* something is bad (performance, maintenance, scalability, etc.),
>>> and
>>> how to correct it *easily*.  Something like the J2EE BluePrint document
>>> would be best.  We need to demonstrate how certain designs just work
>>> better,
>>> and aren't that much more difficult to do.
>>>
>>> Some things are difficult to do, because of the impact on existing use.
 >>>
>>> Example: Pooling components is a valid
>>> proposition.
>>> You could have fewer instances of components than threads of execution
>>> (as
>>> opposed to the more common case in Cocoon where there are multiple
>>> instances per thread of execution).  However, removing the release()
>>> method
>>> has incredible consequences on existing code for only a little ease in
>>> the container.
>>>
 >>> Bottom line:
 >>>
>>> Unless we provide a fundamentally *better* approach that does not 
>>> increase the conceptual and implementative burden on our
>>> users, the proposed approach is flawed.  It is like when England raised
>>> taxes on American soil without giving them representation in parliament.
>>> The Americans eventually revolted, casting all things English aside.  It
>>> wasn't until much later that America and England could stand each other
>>> enough to resume trade relations.
>>>
>>> This is *not* what we want for Avalon.  Any feature we remove *must*
>>> be replaced with something better.
>>
>> Do you mind if I put it in the Avalon docs?
>>
> -1
> See prev. email for reasons.

Is this better?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Under Promise, Over Deliver

[Stephen McConnell <mc...@osm.net>]

Nicola Ken Barozzi wrote:

> Berin Loritsch wrote:
>
>> In my experiences with computing, the company's motto that impressed me
>> the most was Be, Inc.  Jean Louis Gasse' (sp?) was a genious for
>> promoting
>> the mindset of "Under Promise, Over Deliver".  For a commercial company
>> it really hampers the marketing department, but for an OSS project it is
>> the only mindset to have.
>>
>> There are some key obstacles that seem to be in our way of achieving
>> this goal:
>>
>> 1) Over design, under simplification
>> 2) Big ego, small content
>>
>> The big ego, small content has already been hammered on, so we will try
>> to keep the signal to noise ratio down.
>>
>> So far the most productive thread we have had was the "Fresh
>> Perspective",
>> as I finally got what Stephen and Peter were pushing (although at first
>> it was just Stephen).  There is a lot to like in it.
>>
>> Our biggest problem is Over Design, Under Simplification.  The job of a
>> *usable* framework is to enable things to be done that otherwise could
>> not be done.  Avalon 4 does this quite well.  There are some things that
>> does not sit well with me in the track we are on for A5.  They are
>> listed
>> below:
>>
>> 1) The container specification is becoming quite complex.  The
>> complexity
>>    is hoped to be made up for by a "ContainerKit", but if someone wanted
>>    to discard the container kit and create their own container from
>> scratch
>>    it is approaching the level of needing a company to finance the
>>    proposition.  This is not good.
>>
>> 2) We are pushing *more* of the burden of design, thread safety issues,
>>    etc. on the component developer.  This is a *bad* choice.  ColdFusion
>>    4 tried to automatically handle the locking of CF script variables,
>>    but did a poor job of it.  Their solution was to offload that
>>    responsibility to the page developers.  By CF 4.5, we had a product
>> that
>>    needed to be revamped to explicitly handle locking of variables.  We
>>    are making the same mistake regarding pooling of components.
>>
>> 3) If anything, we want to make it *easier* to use.  Even better we want
>>    to make it *easier* to use correctly.  While it is a design goal to
>>    encourage good practices and discourage bad practices, we can't all
>>    do that at the interface level.  People follow examples, good or bad.
>>
>> Now documentation and examples are something we can do in A4.  However
>> it
>> is the type of examples that need to make sense.  We need to demonstrate
>> *why* something is bad (performance, maintenance, scalability, etc.),
>> and
>> how to correct it *easily*.  Something like the J2EE BluePrint document
>> would be best.  We need to demonstrate how certain designs just work
>> better,
>> and aren't that much more difficult to do.
>>
>> Some things are difficult to do.  Pooling components is a valid
>> proposition.
>> You could have fewer instances of components than threads of execution
>> (as
>> opposed to the more common case in Cocoon where there are multiple
>> instances per thread of execution).  However, removing the release()
>> method
>> has incredible consequences on existing code for only a little ease in
>> the container.
>>
>> As Benjamin Franklin said, "They that give up essential liberty to
>> obtain a
>> little temporary safety deserve neither liberty nor safety."  While
>> it has more to do with patriotism than with development, it still
>> applies.
>>
>> Unless we provide a fundamentally *better* approach that does not tax
>> our
>> users, the proposed approach is flawed.  It is like when England raised
>> taxes on American soil without giving them representation in parliament.
>> The Americans eventually revolted, casting all things English aside.  It
>> wasn't until much later that America and England could stand each other
>> enough to resume trade relations.
>>
>> This is *not* what we want for Avalon.  Any freedom we remove *must*
>> be replaced with something better.
>
>
> *clapping hands wildly*
>
> I think that this can be our vision for now.
>
> Do you mind if I put it in the Avalon docs?
>
-1
See prev. email for reasons.
Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Under Promise, Over Deliver

[Peter Donald <pe...@apache.org>]

At 11:13 AM 6/20/2002 -0400, you wrote:
>I'm new to Avalon, and one thing I love about this project is the 
>design.  Most OSS projects implement first and design later (similar to 
>Cocoon :-)  I personally think Avalon is one of the best examples of good 
>Software Engineering in the OSS world (and like wise Cocoon 2)


As a sidenote. If you want to have a look at a nicely designed OSS project 
have a look at Tomcat4/Catalina. Last I looked at it, it lacked performance 
but had a nicely thought out design.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Under Promise, Over Deliver

[Michael Stanley <ms...@mitre.org>]

Very Well Written!   In fact I've passed it on to my department and 
asked everyone to consider it in our own development strategy.  The 
problems you describe and new mindset you are promoting, can be applied 
to all projects.

Just one thing though.  I don't view 'Over Design' as a bad thing. 
Nothing bad has come out of projects that spend a lot of time designing, 
however estimating the achievable time frames is often miscalculated.

I'm new to Avalon, and one thing I love about this project is the 
design.  Most OSS projects implement first and design later (similar to 
Cocoon :-)  I personally think Avalon is one of the best examples of 
good Software Engineering in the OSS world (and like wise Cocoon 2)

I'm looking forward to working more with the Avalon Framework.  Keep up 
the good work.

<Mike/>

Nicola Ken Barozzi wrote:
> 
> 
> Leo Simons wrote:
> 
>> On Thu, 2002-06-20 at 15:27, Nicola Ken Barozzi wrote:
>>
>>> Berin Loritsch wrote:
>>>
>>>> In my experiences with computing, the company's motto that impressed me
>>>> the most was Be, Inc.  Jean Louis Gasse' (sp?) was a genious for
>>>> promoting
>>>> the mindset of "Under Promise, Over Deliver".  For a commercial company
>>>> it really hampers the marketing department, but for an OSS project 
>>>> it is
>>>> the only mindset to have.
>>>>
>>>> There are some key obstacles that seem to be in our way of achieving
>>>> this goal:
>>>>
>>>> 1) Over design, under simplification
>>>> 2) Big ego, small content
>>>>
>>>> The big ego, small content has already been hammered on, so we will try
>>>> to keep the signal to noise ratio down.
>>>>
>>>> So far the most productive thread we have had was the "Fresh
>>>> Perspective",
>>>> as I finally got what Stephen and Peter were pushing (although at first
>>>> it was just Stephen).  There is a lot to like in it.
>>>>
>>>> Our biggest problem is Over Design, Under Simplification.  The job of a
>>>> *usable* framework is to enable things to be done that otherwise could
>>>> not be done.  Avalon 4 does this quite well.  There are some things 
>>>> that
>>>> does not sit well with me in the track we are on for A5.  They are
>>>> listed
>>>> below:
>>>>
>>>> 1) The container specification is becoming quite complex.  The
>>>> complexity
>>>>   is hoped to be made up for by a "ContainerKit", but if someone wanted
>>>>   to discard the container kit and create their own container from
>>>> scratch
>>>>   it is approaching the level of needing a company to finance the
>>>>   proposition.  This is not good.
>>>>
>>>> 2) We are pushing *more* of the burden of design, thread safety issues,
>>>>   etc. on the component developer.  This is a *bad* choice.  ColdFusion
>>>>   4 tried to automatically handle the locking of CF script variables,
>>>>   but did a poor job of it.  Their solution was to offload that
>>>>   responsibility to the page developers.  By CF 4.5, we had a product
>>>> that
>>>>   needed to be revamped to explicitly handle locking of variables.  We
>>>>   are making the same mistake regarding pooling of components.
>>>>
>>>> 3) If anything, we want to make it *easier* to use.  Even better we 
>>>> want
>>>>   to make it *easier* to use correctly.  While it is a design goal to
>>>>   encourage good practices and discourage bad practices, we can't all
>>>>   do that at the interface level.  People follow examples, good or bad.
>>>>
>>>> Now documentation and examples are something we can do in A4.  However
>>>> it
>>>> is the type of examples that need to make sense.  We need to 
>>>> demonstrate
>>>> *why* something is bad (performance, maintenance, scalability, etc.),
>>>> and
>>>> how to correct it *easily*.  Something like the J2EE BluePrint document
>>>> would be best.  We need to demonstrate how certain designs just work
>>>> better,
>>>> and aren't that much more difficult to do.
>>>>
>>>> Some things are difficult to do.  Pooling components is a valid
>>>> proposition.
>>>> You could have fewer instances of components than threads of execution
>>>> (as
>>>> opposed to the more common case in Cocoon where there are multiple
>>>> instances per thread of execution).  However, removing the release()
>>>> method
>>>> has incredible consequences on existing code for only a little ease in
>>>> the container.
>>>>
>>>> As Benjamin Franklin said, "They that give up essential liberty to
>>>> obtain a
>>>> little temporary safety deserve neither liberty nor safety."  While
>>>> it has more to do with patriotism than with development, it still
>>>> applies.
>>>>
>>>> Unless we provide a fundamentally *better* approach that does not tax
>>>> our
>>>> users, the proposed approach is flawed.  It is like when England raised
>>>> taxes on American soil without giving them representation in 
>>>> parliament.
>>>> The Americans eventually revolted, casting all things English 
>>>> aside.  It
>>>> wasn't until much later that America and England could stand each other
>>>> enough to resume trade relations.
>>>>
>>>> This is *not* what we want for Avalon.  Any freedom we remove *must*
>>>> be replaced with something better.
>>>
>>>
>>> *clapping hands wildly*
>>>
>>> I think that this can be our vision for now.
>>>
>>> Do you mind if I put it in the Avalon docs?
>>
>>
>>
>> as long as it is under TODO or somethin. I don't really want anything
>> about A5 mentioned in a prominent place on the site. Also, it'd not be
>> so cool if we said on the main site "we have big egos, little content,
>> and too much design".
>>
>> Hope you see what I'm getting at...
> 
> 
> Ok, you're right, I meant to keep the "vision", not the "mea culpa"; 
> I'll commit it to xdocs for reviewing, but not push it to the site yet.
> 


-- 
<Mike/>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Under Promise, Over Deliver

[Nicola Ken Barozzi <ni...@apache.org>]

Leo Simons wrote:
> On Thu, 2002-06-20 at 15:27, Nicola Ken Barozzi wrote:
> 
>>Berin Loritsch wrote:
>>
>>>In my experiences with computing, the company's motto that impressed me
>>>the most was Be, Inc.  Jean Louis Gasse' (sp?) was a genious for
>>>promoting
>>>the mindset of "Under Promise, Over Deliver".  For a commercial company
>>>it really hampers the marketing department, but for an OSS project it is
>>>the only mindset to have.
>>>
>>>There are some key obstacles that seem to be in our way of achieving
>>>this goal:
>>>
>>>1) Over design, under simplification
>>>2) Big ego, small content
>>>
>>>The big ego, small content has already been hammered on, so we will try
>>>to keep the signal to noise ratio down.
>>>
>>>So far the most productive thread we have had was the "Fresh
>>>Perspective",
>>>as I finally got what Stephen and Peter were pushing (although at first
>>>it was just Stephen).  There is a lot to like in it.
>>>
>>>Our biggest problem is Over Design, Under Simplification.  The job of a
>>>*usable* framework is to enable things to be done that otherwise could
>>>not be done.  Avalon 4 does this quite well.  There are some things that
>>>does not sit well with me in the track we are on for A5.  They are
>>>listed
>>>below:
>>>
>>>1) The container specification is becoming quite complex.  The
>>>complexity
>>>   is hoped to be made up for by a "ContainerKit", but if someone wanted
>>>   to discard the container kit and create their own container from
>>>scratch
>>>   it is approaching the level of needing a company to finance the
>>>   proposition.  This is not good.
>>>
>>>2) We are pushing *more* of the burden of design, thread safety issues,
>>>   etc. on the component developer.  This is a *bad* choice.  ColdFusion
>>>   4 tried to automatically handle the locking of CF script variables,
>>>   but did a poor job of it.  Their solution was to offload that
>>>   responsibility to the page developers.  By CF 4.5, we had a product
>>>that
>>>   needed to be revamped to explicitly handle locking of variables.  We
>>>   are making the same mistake regarding pooling of components.
>>>
>>>3) If anything, we want to make it *easier* to use.  Even better we want
>>>   to make it *easier* to use correctly.  While it is a design goal to
>>>   encourage good practices and discourage bad practices, we can't all
>>>   do that at the interface level.  People follow examples, good or bad.
>>>
>>>Now documentation and examples are something we can do in A4.  However
>>>it
>>>is the type of examples that need to make sense.  We need to demonstrate
>>>*why* something is bad (performance, maintenance, scalability, etc.),
>>>and
>>>how to correct it *easily*.  Something like the J2EE BluePrint document
>>>would be best.  We need to demonstrate how certain designs just work
>>>better,
>>>and aren't that much more difficult to do.
>>>
>>>Some things are difficult to do.  Pooling components is a valid
>>>proposition.
>>>You could have fewer instances of components than threads of execution
>>>(as
>>>opposed to the more common case in Cocoon where there are multiple
>>>instances per thread of execution).  However, removing the release()
>>>method
>>>has incredible consequences on existing code for only a little ease in
>>>the container.
>>>
>>>As Benjamin Franklin said, "They that give up essential liberty to
>>>obtain a
>>>little temporary safety deserve neither liberty nor safety."  While
>>>it has more to do with patriotism than with development, it still
>>>applies.
>>>
>>>Unless we provide a fundamentally *better* approach that does not tax
>>>our
>>>users, the proposed approach is flawed.  It is like when England raised
>>>taxes on American soil without giving them representation in parliament.
>>>The Americans eventually revolted, casting all things English aside.  It
>>>wasn't until much later that America and England could stand each other
>>>enough to resume trade relations.
>>>
>>>This is *not* what we want for Avalon.  Any freedom we remove *must*
>>>be replaced with something better.
>>
>>*clapping hands wildly*
>>
>>I think that this can be our vision for now.
>>
>>Do you mind if I put it in the Avalon docs?
> 
> 
> as long as it is under TODO or somethin. I don't really want anything
> about A5 mentioned in a prominent place on the site. Also, it'd not be
> so cool if we said on the main site "we have big egos, little content,
> and too much design".
> 
> Hope you see what I'm getting at...

Ok, you're right, I meant to keep the "vision", not the "mea culpa"; 
I'll commit it to xdocs for reviewing, but not push it to the site yet.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Under Promise, Over Deliver

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

On Thu, 2002-06-20 at 15:27, Nicola Ken Barozzi wrote:
> Berin Loritsch wrote:
> > In my experiences with computing, the company's motto that impressed me
> > the most was Be, Inc.  Jean Louis Gasse' (sp?) was a genious for
> > promoting
> > the mindset of "Under Promise, Over Deliver".  For a commercial company
> > it really hampers the marketing department, but for an OSS project it is
> > the only mindset to have.
> > 
> > There are some key obstacles that seem to be in our way of achieving
> > this goal:
> > 
> > 1) Over design, under simplification
> > 2) Big ego, small content
> > 
> > The big ego, small content has already been hammered on, so we will try
> > to keep the signal to noise ratio down.
> > 
> > So far the most productive thread we have had was the "Fresh
> > Perspective",
> > as I finally got what Stephen and Peter were pushing (although at first
> > it was just Stephen).  There is a lot to like in it.
> > 
> > Our biggest problem is Over Design, Under Simplification.  The job of a
> > *usable* framework is to enable things to be done that otherwise could
> > not be done.  Avalon 4 does this quite well.  There are some things that
> > does not sit well with me in the track we are on for A5.  They are
> > listed
> > below:
> > 
> > 1) The container specification is becoming quite complex.  The
> > complexity
> >    is hoped to be made up for by a "ContainerKit", but if someone wanted
> >    to discard the container kit and create their own container from
> > scratch
> >    it is approaching the level of needing a company to finance the
> >    proposition.  This is not good.
> > 
> > 2) We are pushing *more* of the burden of design, thread safety issues,
> >    etc. on the component developer.  This is a *bad* choice.  ColdFusion
> >    4 tried to automatically handle the locking of CF script variables,
> >    but did a poor job of it.  Their solution was to offload that
> >    responsibility to the page developers.  By CF 4.5, we had a product
> > that
> >    needed to be revamped to explicitly handle locking of variables.  We
> >    are making the same mistake regarding pooling of components.
> > 
> > 3) If anything, we want to make it *easier* to use.  Even better we want
> >    to make it *easier* to use correctly.  While it is a design goal to
> >    encourage good practices and discourage bad practices, we can't all
> >    do that at the interface level.  People follow examples, good or bad.
> > 
> > Now documentation and examples are something we can do in A4.  However
> > it
> > is the type of examples that need to make sense.  We need to demonstrate
> > *why* something is bad (performance, maintenance, scalability, etc.),
> > and
> > how to correct it *easily*.  Something like the J2EE BluePrint document
> > would be best.  We need to demonstrate how certain designs just work
> > better,
> > and aren't that much more difficult to do.
> > 
> > Some things are difficult to do.  Pooling components is a valid
> > proposition.
> > You could have fewer instances of components than threads of execution
> > (as
> > opposed to the more common case in Cocoon where there are multiple
> > instances per thread of execution).  However, removing the release()
> > method
> > has incredible consequences on existing code for only a little ease in
> > the container.
> > 
> > As Benjamin Franklin said, "They that give up essential liberty to
> > obtain a
> > little temporary safety deserve neither liberty nor safety."  While
> > it has more to do with patriotism than with development, it still
> > applies.
> > 
> > Unless we provide a fundamentally *better* approach that does not tax
> > our
> > users, the proposed approach is flawed.  It is like when England raised
> > taxes on American soil without giving them representation in parliament.
> > The Americans eventually revolted, casting all things English aside.  It
> > wasn't until much later that America and England could stand each other
> > enough to resume trade relations.
> > 
> > This is *not* what we want for Avalon.  Any freedom we remove *must*
> > be replaced with something better.
> 
> *clapping hands wildly*
> 
> I think that this can be our vision for now.
> 
> Do you mind if I put it in the Avalon docs?

as long as it is under TODO or somethin. I don't really want anything
about A5 mentioned in a prominent place on the site. Also, it'd not be
so cool if we said on the main site "we have big egos, little content,
and too much design".

Hope you see what I'm getting at...

cheers,

- Leo



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Under Promise, Over Deliver

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

<snip/>
> > This is *not* what we want for Avalon.  Any freedom we 
> remove *must* 
> > be replaced with something better.
> 
> *clapping hands wildly*
> 
> I think that this can be our vision for now.
> 
> Do you mind if I put it in the Avalon docs?


No problem man! Go for it.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Under Promise, Over Deliver

[Nicola Ken Barozzi <ni...@apache.org>]

Berin Loritsch wrote:
> In my experiences with computing, the company's motto that impressed me
> the most was Be, Inc.  Jean Louis Gasse' (sp?) was a genious for
> promoting
> the mindset of "Under Promise, Over Deliver".  For a commercial company
> it really hampers the marketing department, but for an OSS project it is
> the only mindset to have.
> 
> There are some key obstacles that seem to be in our way of achieving
> this goal:
> 
> 1) Over design, under simplification
> 2) Big ego, small content
> 
> The big ego, small content has already been hammered on, so we will try
> to keep the signal to noise ratio down.
> 
> So far the most productive thread we have had was the "Fresh
> Perspective",
> as I finally got what Stephen and Peter were pushing (although at first
> it was just Stephen).  There is a lot to like in it.
> 
> Our biggest problem is Over Design, Under Simplification.  The job of a
> *usable* framework is to enable things to be done that otherwise could
> not be done.  Avalon 4 does this quite well.  There are some things that
> does not sit well with me in the track we are on for A5.  They are
> listed
> below:
> 
> 1) The container specification is becoming quite complex.  The
> complexity
>    is hoped to be made up for by a "ContainerKit", but if someone wanted
>    to discard the container kit and create their own container from
> scratch
>    it is approaching the level of needing a company to finance the
>    proposition.  This is not good.
> 
> 2) We are pushing *more* of the burden of design, thread safety issues,
>    etc. on the component developer.  This is a *bad* choice.  ColdFusion
>    4 tried to automatically handle the locking of CF script variables,
>    but did a poor job of it.  Their solution was to offload that
>    responsibility to the page developers.  By CF 4.5, we had a product
> that
>    needed to be revamped to explicitly handle locking of variables.  We
>    are making the same mistake regarding pooling of components.
> 
> 3) If anything, we want to make it *easier* to use.  Even better we want
>    to make it *easier* to use correctly.  While it is a design goal to
>    encourage good practices and discourage bad practices, we can't all
>    do that at the interface level.  People follow examples, good or bad.
> 
> Now documentation and examples are something we can do in A4.  However
> it
> is the type of examples that need to make sense.  We need to demonstrate
> *why* something is bad (performance, maintenance, scalability, etc.),
> and
> how to correct it *easily*.  Something like the J2EE BluePrint document
> would be best.  We need to demonstrate how certain designs just work
> better,
> and aren't that much more difficult to do.
> 
> Some things are difficult to do.  Pooling components is a valid
> proposition.
> You could have fewer instances of components than threads of execution
> (as
> opposed to the more common case in Cocoon where there are multiple
> instances per thread of execution).  However, removing the release()
> method
> has incredible consequences on existing code for only a little ease in
> the container.
> 
> As Benjamin Franklin said, "They that give up essential liberty to
> obtain a
> little temporary safety deserve neither liberty nor safety."  While
> it has more to do with patriotism than with development, it still
> applies.
> 
> Unless we provide a fundamentally *better* approach that does not tax
> our
> users, the proposed approach is flawed.  It is like when England raised
> taxes on American soil without giving them representation in parliament.
> The Americans eventually revolted, casting all things English aside.  It
> wasn't until much later that America and England could stand each other
> enough to resume trade relations.
> 
> This is *not* what we want for Avalon.  Any freedom we remove *must*
> be replaced with something better.

*clapping hands wildly*

I think that this can be our vision for now.

Do you mind if I put it in the Avalon docs?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Under Promise, Over Deliver

[Leo Simons <ls...@multimia.com>]

On Thu, 2002-06-20 at 17:27, Leo Sutic wrote:
> I think you hit the nail on the head there, Berin.
> 
> However, I also think that there are things that need to be
> fixed. Stephen and Peter's proposal regarding role names
> is one of them. I had a similar proposal.
> 
> The thing is that many of the proposals that we have
> are aimed at different complexities of containers.
> On one hand, having lots of features in the container
> is good, because it scales very well. On the other hand,
> it makes it more difficult to work with.
> 
> We have proposals for component-specific namespaces,
> automatic release of components, pluggable policies,
> etc...
> 
> I just do not know how to move forward from this point.
> 
> I do believe that we all agree on the purpose of the
> most proposals. For example, anyone disagrees that the
> ComponentSelectors, as they work now, are bad?
> 
> But if we go on without structuring this up I think we'll 
> all just restate our proposals as we have multiple times, 
> we will talk past each other, and bang boom we're back to 
> no progress.
> 
> Anyone have any idea on how to do this?

yup. Don't try to structure the development process too much. Keep an
open mind and develop stuff. When it all matures we'll know which
proposal works best and how to move forward.

that's the open source way, and it works rather well.

cheers,

- Leo



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Under Promise, Over Deliver

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

> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com] 
> I think you hit the nail on the head there, Berin.
> 
> However, I also think that there are things that need to be 
> fixed. Stephen and Peter's proposal regarding role names is 
> one of them. I had a similar proposal.
> 
> The thing is that many of the proposals that we have
> are aimed at different complexities of containers.
> On one hand, having lots of features in the container
> is good, because it scales very well. On the other hand,
> it makes it more difficult to work with.
> 
> We have proposals for component-specific namespaces,
> automatic release of components, pluggable policies,
> etc...
> 
> I just do not know how to move forward from this point.

That's the trick.  I think what we should do at this point
is:

#1) Use Excalibur to work out how the container contracts
    should work.  We need to test the concepts in the field
    before we can say authoritatively that we want to force
    everyone to go in this direction.  That is what happened
    when we abstracted the ComponentSelector, and we see
    where that got us.

#2) We use different subsubprojects to test the different
    proposals.
    + Fortress should test the lifecycle extensions (work
        has already begun on that), and the session object
        proposal.
    + Merlin should perfect the metadata approach to component
        resolution, answering the fundamental question of
        component attributes and metadata management (per
        component or grouping all in a descriptor).

When we have something that we think is ready, we move
forward with the formal proposal.

> 
> I do believe that we all agree on the purpose of the
> most proposals. For example, anyone disagrees that the 
> ComponentSelectors, as they work now, are bad?

The concept behind the CS was good.  The implementation
practices that it allowed were bad.

> 
> But if we go on without structuring this up I think we'll 
> all just restate our proposals as we have multiple times, 
> we will talk past each other, and bang boom we're back to 
> no progress.
> 
> Anyone have any idea on how to do this?

Let's table A5 for a while, finish how we expect to address
the needs we have identified, and how we intend to replace
current functionality with something better later on.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Under Promise, Over Deliver

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

I think you hit the nail on the head there, Berin.

However, I also think that there are things that need to be
fixed. Stephen and Peter's proposal regarding role names
is one of them. I had a similar proposal.

The thing is that many of the proposals that we have
are aimed at different complexities of containers.
On one hand, having lots of features in the container
is good, because it scales very well. On the other hand,
it makes it more difficult to work with.

We have proposals for component-specific namespaces,
automatic release of components, pluggable policies,
etc...

I just do not know how to move forward from this point.

I do believe that we all agree on the purpose of the
most proposals. For example, anyone disagrees that the
ComponentSelectors, as they work now, are bad?

But if we go on without structuring this up I think we'll 
all just restate our proposals as we have multiple times, 
we will talk past each other, and bang boom we're back to 
no progress.

Anyone have any idea on how to do this?

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>