On Tue, 20 Aug 2002, Marcus Crafter wrote:
> On Tue, Aug 20, 2002 at 04:13:35PM +0200, Giacomo Pati wrote:
> > On Tue, 20 Aug 2002, Marcus Crafter wrote:
> > >
> > > I'd always envisioned Blocks to be a better way to architect and
> > > design your application (more on the side of large scale apps
> > > rather than small), whereas Modules being the ability to plug
> > > functionality into Cocoon to keep the core small and to be
> > > able to package your application with what you need rather than the
> > > whole Cocoon distribution.
> >
> > And Blocks have abstraction in mind. A interface definition (this is not a
> > java interface but something more of that concept of meta data definition)
> > gives an other Block the possibility to "programm" against it. The
> > deployer is free to choose whichever implementation of that interface he
> > likes (if there will be more than one). See my mail here
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102941595120561&w=2
>
> Thanks for the reference, I'll have a look at it.
>
> ..<snip/>..
> > > Note that this is separate from Modules - a particular block might
> > > require particular modules to be present for its features to work.
> >
> > As well as other blocks.
>
> Yes.
>
> > > Blocks can have dependancies and can communiate with other blocks via
> > > sessions, etc,
> >
> > The proposed way for inter block communication was a protocol like
> > "block:skip:/adtd2html" for easier separation of interface and
> > implementation.
>
> *nod*.
Sorry, typo. Should read "block:skin:..."
>
> So the skip:/adtd2html part actually defines part of the
> block interface you were describing above.
Yes, the discussion was should things like skin:adtd2html" be validated
(automatically by the deploying mechanism) or simply contracted by a
description (for easier implementation). Stefano and I thopught
that the validation process could grow into unforseeable depdth.
> You could have a 'gcSkip' and a 'mcSkip' that provides the 'skip'
> interface and both implemntations would be considered
> equal ?
Yup.
>
> > > 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?
> ie. a module is something like a jsp.jar which includes all thats
> necessary to use jsp's inside your cocoon app. A fop module
> includes all that's necessary to use fop.
Ok, I see.
> 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
> Is that how you understand it too ?
>
> > > 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.
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).
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.
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.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
