cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: Roadmap for Cocoon Blocks
Date Wed, 12 Oct 2005 15:02:35 GMT
On 12 Oct 2005, at 15:21, Daniel Fagerstrom wrote:
> Pier Fumagalli wrote:
>> On 12 Oct 2005, at 12:40, Daniel Fagerstrom wrote:
>>> Pier Fumagalli wrote:
>>>> On 11 Oct 2005, at 20:16, Bertrand Delacretaz wrote:
>>>>
>>>>> Just one small nitpicking comment, we should say "3.0 will  
>>>>> *most   probably* use OSGI" - as you said, it's a nice goal to  
>>>>> have but  I  don't think we're 100% positive on that yet, there  
>>>>> are still a  few  unknowns.
>>>>>
>>>>
>>>> I agree wholeheartedly... I am not 100% sure that OSGI is the   
>>>> perfect  solution. AFAICS it's a little bit too cumbersome for  
>>>> my  brain.
>>>>
>>>> And I know a lot of others share my concerns (from discussions  
>>>> at  the  GT).
>>>>
>>>
>>> Any specific concerns about OSGi?
>>>
>>
>> Personally, it looks "cumbersome" to me... Heck, I'm writing an   
>> Eclipse plugin at the moment, and if it wasn't for the Eclipse  
>> Plugin  editor and stuff, I'd be totally lost.
>
> OSGi gives us classloader isolation and the possibility of hot  
> plugabillity. Both are rather complex areas, and things that we  
> require from the real block system, so some extra complexity is  
> hard to avoid.

Classloader isolation is quite neat, I have to admit that, but it's  
not a major difficulty to implement on top of existing frameworks...

> 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...

But that's a feeling, I'm far from saying "No, let's use something  
else", don't get me wrong...

>> Since the flow came along, I got quite lazy (weakly typed  
>> languages  rule) and the complexity of writing (and maintaining) a  
>> set of  metadata files related to each individual block, on top of  
>> sitemaps,  wirings, xconfs, source Java files and so on is  
>> definitely not  appealing to me.
>
> For the Manifest.mf, the only complexity I have experienced is  
> maintaining the export and import of packages. There are several  
> things to say about that: First there are tool support to help you,  
> Eclipse e.g. There is  also a tool for calculating dependencies  
> between the bundles: http://oscar-osgi.sourceforge.net/mangen/,  
> that we maybe could use in our build process. You can also simplify  
> export and import rules by using wildcards.
>
> But IMO there is a more important aspect of imports and exports:  
> they declare what your bundle export and import and if they are  
> complicated, that often mean that your bundle doesn't have a  
> focused concern area and that its interface to the rest of the  
> world is fat. This leads to rigid systems that are hard to reuse.  
> So it is true that the current "bundleization" of Cocoon have  
> complicated export and import section. I don't see that as a  
> problem with OSGi, but rather as a consequnce of what we all  
> allready know: Cocoon is monolothic, have far to much inter  
> dependencies and fat interfaces and it is not that well defined  
> what sub parts there are.

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: http://www.betaversion.org/~pier/ 
2005/07/dependancies-through-import-statements.html

I like the simplicity that Leo outlined...

> As soon as the basic mechanisms are in place I and hopefully others  
> will focus on  geting the contracts leaner.

Yep... We need to see what the future holds...

>> I'm wondering if there isn't an easier (simpler) way to approach  
>> the  problem.
>
> Sure, don't we all ;) We can of course wait for ever on the perfect  
> approach for real block. But after having waited for the for 3+  
> years, I and some others wanted something good enough now rather  
> than something perfect in the future.
>
> For your core, you might remeber that I supported that we should  
> use it and wanted to start working on it, but you never found time  
> to answer my qustions about some of the concepts in it or commit  
> the much improved version of it that you said that you had.

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...

That's why I'm not saying "let's move away from OSGI", but just  
outlining the fact that I personally find it quite cumbersome, and  
that what I like most is simplicity...


>> If we go down the OSGI route, I'll code  for OSGI, not for some  
>> pseudo-adapter of some sort... I'm not one to  take shortcuts.
>
> I can agree with that attitude, even if I think most users will be  
> quite happy to be able to use their favorit component container.

You know how I am :-) I don't like hacks, or one-fits-all things...

I just wish I had more time! :-P

     Pier




Mime
View raw message