cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Cocoonlet
Date Sun, 01 May 2005 14:05:53 GMT
Sylvain Wallez wrote:
> Sylvain Wallez wrote:
>> Daniel Fagerstrom wrote:
>>> Our current (controversial ;) ) plan is to consider the sitemap and 
>>> the component aspect of the original block proposal as separate 
>>> concerns and (at least initially) solve them separately.
>> Damn, I skipped this whole thread because I was overly swamped, but I 
>> definitely missed something. By separate concerns, do you mean 
>> separate deployment units?
> Sorry to have skipped this. I was swamped and got burned out. A vacation 
> week and things are better now :-)

Glad to hear that you feel better.

> Anyway, I went back in time and read the whole thread. I totally agree 
> that code blocks and sitemap blocks (or whatever their names) are 
> different concerns, but IMO they don't need to be separated in terms of 
> deployment units. These are different layers of functionnality solving 
> different problems.
> We can consider not 2, but 3 kinds of things a block can provide to 
> other blocks:
> 1 - pipeline services, i.e. a block behaves like a mountable subsitemap
> 2 - sitemap components, i.e. generators, transformers, etc.
> 3 - other components
> The main difference between 2 and 3 is that in case 2, the block 
> provides implementations of core interfaces, thus not having to expose 
> its internal classes. In case 3 however, the component has to expose 
> some of its classes, and other blocks have to be aware of them in order 
> to use them, hence the classloading problems mentioned in the discussion.

Same kind of deployment unit but different contracts sounds good to me.

> Now let's look at things from a different POV: let's consider that the 
> core itself is a block, with private and public classes. What do we have 
> now? A bunch of connected "blocks", "bundle" or "plugins" providing 
> classes and services (i.e. component roles), and one of these services 
> can be the pipelines services mentioned in case 1 above.
> And this architecture seriously looks like the Eclipse runtime: a small 
> core kernel that manages plugins, whatever they are, and a lot of 
> plugins that define what your application actually is. This kernel 
> manages plugin dependencies, including classloading, versioning (even 
> several versions in a single application), automatic and remote update, 
> security, etc. Plugins can also define and provide "extension points" 
> that seem to fit with what we need for blocks to provide services, etc. 
> Have a look at the Eclipse FAQ book [1], particularily chapter 5 (even 
> if targeted at Eclipse 3.0, most information is still accurate).
> So why reinvent the wheel, especially a complex one? IMO it would really 
> be interesting to study carefully what the Eclipse runtime can provide 
> us. They worked for years on this problem, and one the major new 
> features in Eclipse 3.1 is the RCP (rich client platform) which is 
> basically a naked kernel with the minimal plugin management stuff on 
> which you plug whatever plugin you need for your application. There's 
> even some ongoing effort on "ERCP", a super-small embeddable RCP.
> By using the Eclipse kernel, Cocoon could be the first RSP, "Rich Server 
> Platform".
> Sylvain
> [1]

Cool! But not that you took my forthcomming RT ;)

I have also been thinking in this direction the last few days. Reinhard 
reminded me about that you had proposed OSGi as a possible 
kernel. So I have taken a look at that and a little bit on Equinox, the 
new Eclipse kernel that is based on OSGi. Other possible kernels are 
Pier's, the Geronimo kernel and Metro. Of these I find Eclipse/OSGi the 
far most promissing.

I agree completely with that a micro kernel Cocoon is the way to go. It 
would as you say give most of what we want for blocks and also numerous 
other possiblities in building Cocoon based apps. It would also help us 
in getting Cocoon far more managable if we package it as a bunch of bundles.

I'm making good progess with the pipeline service aspect of blocks and 
will hopefully be able to check in some code for it soon. When we have a 
working prototype of that part, I'm interested in diving into the 
Eclipse stuff.

Have you thought about how to make OSGi work together with ECM++, or can 
they just be considered as different layers?

Anyway, cool stuff :)


View raw message