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".
WDYT?
Sylvain
[1] http://www.eclipsefaq.org/chris/faq/faq-list.html
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 http://www.osgi.org/osgi_technology/index.asp?section=2 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 :)
/Daniel
