cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Cocoonlet
Date Sun, 01 May 2005 12:41:51 GMT
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 :-)

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.

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 




Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message