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
Platform".
WDYT?
Sylvain
[1] http://www.eclipsefaq.org/chris/faq/faq-list.html
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
|