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/ [EMAIL PROTECTED] [EMAIL PROTECTED]
