On Tue, Aug 20, 2002 at 09:35:21PM +0200, Giacomo Pati wrote:
> On Tue, 20 Aug 2002, Marcus Crafter wrote:
>
> > > > but essenentially dropping a Block into your Cocoon
> > > > distribution reserves a part of the uri space for that Block to
> > > > use, kind of like the Tomcat webapps directory. I also thought that
> > > > Blocks could include particular Modules if necessary. eg. part of a
> > > > stocktrader site that generates pdf reports would only require the
> > > > fop module at that level.
> > >
> > > So which is your distinction between modules and block than? In your
> > > explanation they overlap but in "size", right?
> >
> > Not in size but in intent, perhaps the word 'include' was misleading.
> > Essentially I see modules providing specific functionality outside
> > the core (libraries, generators, serializers), but not actually using
> > it, where as blocks use the functionality provided by the core and
> > whatever modules they need (along with any custom components they
> > may have).
>
> So modules seems to me a grouping of related classes as in Excalibur?
Thats essentially how I saw them, but (looking now to the future)
with manifest entries identifying components that should be
automatically loaded and added to the system.
(kind of like
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/assembly/src/etc/demo.mf?rev=1.1&content-type=text/vnd.viewcvs-markup)
> > A block contains the actual application data (sitemap, stylesheets,
> > custom components, configuration, etc) that uses the features
> > provided by the core and these modules (and potentially other blocks)
> >
> > When I said 'include' I mean't that the .cob could contain
> > actual module jar's itself if they weren't going to be used anywhere
> > else in the application (localizing and allowing blocks to use
> > different versions of the same library if needed).
>
> Well, the intent of Stefanos RT about blocks was that even such "modules"
> would be implemented as Blocks because the provide specialized
> functionallity
>
> We identified different types of Blocks:
>
> Visible Block
> A Block that has a URI attached (mounted) as the WebMail Block in
> my previous mail
>
> Invisible Block
> A Block that provides "internal URIs" (via block: protocol) as the
> Skin-Block or the Access-Block mentioned in the same mail
>
> Functional Block: one that provides components only
Right. The list of block types makes things a bit clearer. Using the
above list Modules as I described them are essentially
'functional blocks'.
> > > > I think there were also discussions/thoughts about having
> > > > hierarchical blocks, meaning you could place common parts of
> > > > your application at a higher level with lower level blocks depending
> > > > on it (ie. not needing to have common classes/files duplicated).
> > > > There was also some talk of remote blocks, ie. being able to
> > > > reference a block running on another server.
> > > >
> > > > Regardless of if/how it happens, I think the concept of modules,
> > > > essentially being able to automatically plug in features needs to
> > > > come first, although to implement it properly we probably need to
> > > > look at moving away from ECM, and using something like Merlin, or
> > > > a combined Merlin/Fortress container.
> > >
> > > Exactly. If you think about a Merlin/Fortress marriage you probably are at
> > > the pre Block level. Extend them to interconnect different block with
> > > the block: protocol and you'll be there.
> >
> > Yes. Merlin/Fortress supports hierarchical containers which I think
> > fits the model well - each block could run inside its own container
> > (something like a BlockContainer) and communicate with other
> > containers via the block: protocol, etc.
>
> Exactly. Now, Carsten can you see your bits and bytes flowing ;)
>
> > Merlin already supports the dependancy, versioning and assembly
> > requirements blocks would have too.
>
> Someone who is getting what Block can be.
>
> Look how hard deployment can be today with our one and only cocoon.xconf
> file if you plan to deploy more and more "apps" into your Cocoon. I had
> that several times as well as Stefano and thus the RT about Blocks. It's
> not that much about modularisation but more on deployment ease. As long as
> you only have xml/xslt/xsp/gif file to build up your application you'll be
> fine. But if you have to use Avalon Components as well to extend the
> functionallity you get into needless configuration issues as there will
> only be one single Classloader for the components defined in cocoon.xconf.
Yes, these issues have been brought up many times on the list.
The Merlin approach to the component configuration issue is to have a
.xinfo file under the same name (including package) as the
component's class name.
ie. hsqldb would have:
org.apache.cocoon.components.hsqldb.class
org.apache.cocoon.components.hsqldb.xinfo
and potentially a:
org.apache.cocoon.components.hsqldb.xprofile
These are known as the x-files :) and contain the role the
particular component provides, dependancies that component has on
other components, context dependancies, lifecycle extension
definitions & dependancies, logging categories, version
information, and more.
One then places manifest entries in your jar file, something like:
Name: org/apache/cocoon/components/hsqldb/ServerImpl.class
Avalon: Type
and Merlin does the rest - the component is automatically loaded,
and if valid (ie. all dependancies can be satisfied) it's
available for use. There's no need to tweak a .roles file or copy
a xml fragment into a .xconf file.
IMO that would be awesome to have in Cocoon.
> First we need I think is to get rid of the single cocoon.xconf file and
> use Merlin/Fortress to achieve better scalability in terms of deployment
> ease (better separation of groups of components).
I agree. There are some issues with using Merlin/Fortress
(currently being discussed on avalon-dev), but Stephen, Berin and I
are in the process of working them out though. I really hope that we
can get the issues sorted out so that we can start using a much
more advanced container like Merlin/Fortress soon though.
> Next we need to define what meta-data is needed to describe those types
> (maybe there are more types) of Blocks to form descriptors which can be
> used to build up a Container/CM/Sitemap harnessed team for a Block. And of
> course there needs to be some orchestration stuff to guide the traffic
> between Blocks.
*nod* Has there been much work done on that at all ?
> And finally we can build a gui for hot Block deployment, configuration and
> dependancy resolvement form Block repositories all over the net.
:)
> Isn't that a vision that is worth to be analyzed *before* people cry about
> performance. Ease of use weights more than performance in my vision.
> Especially in the situation Cocoon is today in respect of
> application deployment.
Yep, let's solidify the vision and get the ball rolling :)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
