cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Roadmap for Cocoon Blocks
Date Wed, 12 Oct 2005 19:07:27 GMT
Pier Fumagalli wrote:

> On 12 Oct 2005, at 15:21, Daniel Fagerstrom wrote:


>> An advantage of using OSGi instead of a home brewn solution is that  
>> we don't have to solve all these complexity issues ourselves. As an  
>> example there actually allready was an Eclipse plugin editor there  
>> that helped you.
> On that I agree wholeheartedly, mate... Don't get me wrong.
> I'm just seeing my OSGI Eclipse plugin on one side, and the last  
> slide Arje posted during the wrap-up of the GetTogether....  
> "SIMPLICITY" :-) Somehow, I can't feel OSGI is moving us towards that  
> direction...

You know mate, simplicity is my main concern and driving force. Now it 
doesn't get simpler in the first step as we have to let the new stuff 
live side by side with the old stuff. But as soon as we have got the 
things working we can start to split Cocoon in small blocks with well 
defined concern areas. I'm very motivated to get there so I guess I can 
ask you to trust that we are getting there or better help getting there ;)

Also bring something else that I guess that you have to work with it for 
some time to really appriciate. It is like a small operating system with 
a console where you can start and stop blocks, ask about theire state 
and meta data, check the state of the services etc. It is really neat.

> Yep... I feel your pain...
> But thinking about it for a little bit, I'm starting to wonder if  
> there is another way...
> There is still a big nag in my mind, related to what Leo posted a  
> while ago, and outlined here: 
> 2005/07/dependancies-through-import-statements.html
> I like the simplicity that Leo outlined...

I also find it cool. And it would be fun to work on. But for the moment 
I feel more entusiastic about getting something working in realistic 
time and about the possibility to cooperate with other communities than 
about doing container research.


> Dude, your pain is _my_ pain on this topic... Unfortunately my  
> current job doesn't allow me to spend much time on Cocoon itself and  
> related projects (or even on my wife, for that matters!!!).
> Seriously speaking, I wish I could dedicate more time onto this, but  
> for now, I'm tied into writing XSLT and maintaining a huge lump of  
> PERL code, and I can tell you, it's not fun...

Yes I understod that. And after having worked on some other somewhat 
complicated stuff like templates, VPCs, the sitemap parts my experience 
was that even if people was interested, it was next to impossible to get 
much feedback on technical questions. So my conclusion was that even if 
we have many talented people in the community, the fact is that they are 
not interested enough in deep infrastructure stuff to actually spend the 
time in designing and building a container suitable for blocks. So the 
realistic choices was to either use something that existed or don't 
bother about blocks anymore.

> You know how I am :-) I don't like hacks, or one-fits-all things...
> I just wish I had more time! :-P

We all do ;)


View raw message