cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Date Thu, 22 Jul 2004 07:47:26 GMT


Stefano Mazzocchi wrote:
> Ugo Cei wrote:
> 
>> Il giorno 12/lug/04, alle 18:23, Marc Portier ha scritto:
>>
>>> think so too, just needs more wild thinking and somebody doing :-)
>>
>>
>>
>> Since I'm getting more and more bored with my daytime job, I ended up 
>> doing something:
>>
>> http://wiki.apache.org/cocoon/ButterflyManifesto
>>
>> Comments are welcome, flames > /dev/null.
> 
> 
> Avalon is dying (and I'm personally trying to killing it faster) and 
> this status is hurting us (see the stall of the cocoon 2.2 evolution), 
> so I agree with sentiments here that we must do something.
> 
> Changing container is a back-incompatible thing, even if, obviously, we 
> can sandbox existing components into avalon sandbox (as proposed 
> already) so our users should be worried since we care for them.
> 
> You are proposing Springs which is a rather simple, bean based, 
> dependency-injection based framework.
> 

as such it's only doing one thing (well)
which means that by itself it's probably not going to be 'enough' as a 
base for all features our components, and groups of components (blocks?) 
might need

> Alternatives are:
> 
>  - Kernel (written by Pier and designed by Pier and myself)
>  - Merlin
>  - Geronimo Container (also compatible with Springs, from what I hear)
>  - Fortress
> 
> My (obviously biased) view is that cocoon is both a production software 
> and a research project, depending on other communities for our critical 
> foundations turned out to be dangerous.
> 

uh?
this sounds like the avalon experience is suddenly extended to the whole 
world

$ du -sk lib
13782   lib

the sum of avalon and excalibur jars in there is a bit over 800k

> So, the question is: what do we buy in using somebody else's code 
> instead of maintaining our own?
> 

Some prove of the reuse pudding maybe?  Surely that reuse think is more 
beneficial then just the feeling of good common sense?

(By the way: in my head reuse is measured by the ability to throw stuff 
away without jeopardizing the rest)

> For sure it doesn't save us energy, we already have that container build.
> 

Cost of building is a fraction of the cost of maintaining?

(Mind though that spring's core is some 200k, so yeah, it does not look 
like an awful lot of work, but turned around it seems decreasingly 
interesting to forcefully redo it either?)

> For sure it doesn't increase our ability to innovate, since any changes 
> have to go thru another mail list (which, in the Spring case, is not 
> even ASF controlled).
> 

<jokingly>
I'm probably missing something about the subtle way ASF is controlling 
what I'm saying here? Ignorance is bliss, so please don't tell me :-)
</jokingly>

Cluetrain: it (including innovation!) is about conversations, you simply 
don't control where they happen... borders are in our minds

As for innovation discussed on mailinglists: we will could admit that we 
haven't always been eagerly receptive to our internal blend of 
innovation?  Reversing the argument we might question if dipping into a 
pool of people with a somewhat different mindset couldn't be really 
refreshing and nurturing the innovation more then limitiing it. At least 
I would be curious enough to find out.

> For sure it doesn't help us with reusability of code, since we reuse 
> libraries over their interfaces (JCP-standardized or not) and wrap them 
> on our own little pipeline abstractions.
> 

Hm, in my head it's not only about our own code, it's also about the 
additional code our endusers are writing, no?

Mind you: not the custom pipeline-components or other extensions on 
proper cocoon api's (people opting for those will hapilly take some 
cocoon dependency for granted) but the actual business code that needs 
to be blended in (more and more since our growing webapp dev support). 
Today we're advocating to do that through wrapping in avalon components?

I know writing a service wrapper that allows to hook up in avalon isn't 
a big deal, but the none-intrusiveness of the new style of containers 
(zaroo lines of wrapping?) make the ratio go to positive-infinite anyway

> Result, I'm -1 on Spring because we can't control it and -0.5 on 
> Merlin/Fortress/Geronimo because they are other communities with other 
> interests.
> 
> I say we write our stuff and be done with it once and forever.
> 

so what about 'less is more?'
and 'it's not about the code, but about the community?'

I honnestly find your upfront position in this (based on historic 
frustration?) almost elitist.

In principle I'm probably not that far off from your feeling that we 
shouldn't be too shy to go and build what we need and then bravely 
support it. But in practice I see no benefit in redoing what others have 
done, provided it's done well and doesn't require us to drag allong a 
load of stuff we're not asking for.

Starting from Spring's core my expectations would be that there is still 
more than enough stuff that we will need to add ourselves (which is 
resonating with your arguments?)...

To conclude: Even if we later on would decide that spring's core would 
need to be replaced by our own thingy than still, the quick benefits 
IMHO would be
- starting from a spinning wheel rather then re-invent the concept
- broaden our horizon and pull in more views
- get into (and also infect) a more widespread mindshare
- get us started again (thx Ugo!)

Controlling our dependencies to external thingies is a continuous 
concern, this will not be different this time, lessons from the past 
should be applied.

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message