cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: [RT] Finishing the first phase of block design
Date Fri, 10 Oct 2003 02:01:12 GMT
Stefano Mazzocchi wrote:

> On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:
>> Stefano Mazzocchi wrote:
>>> I have updated the block design documents on the wiki. Changes were:
>> ...
>>> A few things are left to decide:
>>>  1) the block metadata information in the block.xml file
>>>   see
>>>  2) how blocks expose classloading to other blocks


>>> Exposing classes
>>> ----------------
>>> Stephen proposed to separate the classes to expose in a different jar 
>>> and expose that. I like this. It's simple and effective.
>>> But instead of declaring classloaders or classpaths in the blocks, I 
>>> propose to extend the block FS layout so that we have
>>> for individual classes and resources:
>>>  /classes
>>>  /classes/public
>>>  /classes/private
>>> for jars:
>>>  /lib
>>>  /lib/public
>>>  /lib/private
>> Hmmm.  That is quite different than what one would expect from the WAR 
>> paradigm, no?  Would
>> COB-INF/[classes|lib]
>> COB-INF/public/[classes|lib]
>> or
>> COB-INF/private/[classes|lib]
>> COB-INF/public/[classes|lib]
>> be any better?
> This might suggest the concept that private is the location of all the 
> things that are private so
>  private/lib
> means "I have libraries in the private section", so maybe I can put 
> something else as well to have it protected? while
>  lib/private
> means "these are the private libraries"... but doesn't say anything 
> about non-lib things. I still like this approach better, even if it 
> moves away from the WAR paradigm (which is not a big deal, IMO, since 
> blocks are different enough already)

Ok, that's a good point.  I have a parallel concern that something like



public Class StillNotFound {...

will pop up regularly on the users list.

One more idea to try to avert potential confusion.



>>> the block manager will tranparently make available the classes found 
>>> in the "public" folders to the blocks that depend on this block (and 
>>> *ONLY* to those! classloading isolation is very important to achieve 
>>> hot deployment functionality without impacting the performance of a 
>>> running system too much)
>> Is there never a way to avoid duplicating common jars between blocks?
> Avoid? well, not architecturally, that could means weird classloading 
> issues.
>> I think we may be wise to go this way but I know this will be 
>> unpopular and misunderstood and deserves some thought.
> good point, though.
>>> the classloader will also check for conflicts: in fact, it will be 
>>> considered an error to depend on two blocks that provide one or more 
>>> classes with the same absolute name.
>> Hmmm.  not sure I can mentally eliminate all valid cases at this 
>> stage.  Would there ever be an older version and a newer version of a 
>> block deployed in the same space for example? (probably not but 
>> thinking out loud)
> Oh, yeah, the above "modulo versioning". If the same class applies in 
> blocks that differ only for their versions, it's good. The problem is 
> when two completely different blocks do. (we might signal a warning 
> instead of an error, but that's an implementation detail).

OK, sounds good.

>> Exposing Resources
>> ------------------
>> I'm adding this because my brain is still a little unsure about this. 
>> So far, we've said that file resources (an xsl for example)
>> 1) need to be exposed via a sitemap pipeline, even if only by a reader
>> 2) are not anywhere declared explicitly (except in the pipeline of 
>> course)
>> 3) are not distinguised from resources meant to be private by any 
>> formal semantics, though this information could be conveyed 
>> human-to-human in any block docs (blocs? blockumentation? ;) ).
>> Here are my oustanding questions:
>> - Will we regret requiring the overhead of pipeline setup (runtime I 
>> mean) for blocks which expose a great deal of otherwise static resources?
> could be. remember though that the block: protocol will be caching 
> friendly, so we might even gain performance.
>> - Not found resources will have to go through every pipeline to 
>> determine that it's not found.  With fallback behavior due to 
>> polymorphism this gets worse.
> I fail to see this, can you explain why you think this is the case?

sitemap references:

block manager has external-skin ->
  -> extends ->

checks WEB-INF/blocks/384938958499/sitemap.xmap (by the way, the Cob 
samples at the wiki don't have sitemaps for the skins blocks which would 
presumably need them to expose their xslt in the example right?)

If that sitemap doesn't override /stylesheets/news2html.xslt, every
pipeline in that sitemap needs to be checked _then_ block manager goes 
on to 

if there are several levels of extension, this could be a long process.

But now a worse thought comes to mind:

suppose has defined

<map:match pattern="stylesheets/*.xslt">
   <map:read src="styles/{1}.xslt"/>

but only wants to
override /stylesheets/news2html.xslt and /stylesheets/another.xslt

if it is allowed it do

<map:match pattern="stylesheets/*.xslt">
   <map:read src="mystyles/{1}.xslt"/>

then we must make the block manager and sitemap engine have a new 
behavior: if a match exists, but the source is not actually found, 
proceed to the super-block etc.  That's a mess, but so is having to set 
up a whole series of identical pipelines for every image, stylesheet, 
etc you need to override from a super-block, isn't it?

Now, perhaps this could be handled in other ways by using selectors 
instead of wildcards in matchers, but this could make writing a block a 
little finicky.  If we decide to go with existing semantics with no 
explicit list of provided or overridden resources, we'll need to think 
through and very clearly document best practices that are not onerous. 
On users for whom this may be a very mindbending concept.

>> - Will not explicitly declaring which resources are meant to be public 
>> cause trouble for block implementors and extenders?
> ?? well, in the sitemap I can be very precise on what I want to expose. 
> and everything else is not exposed. the sitemap is like a virtual file 
> system description, powerful enough to describe all possible systems.
> If you have
> <pipeline block-access="public">

ah, that presupposes the block-access proposal which I think had just 
hit the list when I wrote the above.  I agree that helps.

>> Of course the flexibility of decoupling the uri space from the 
>> filesystem is a benefit - but is it necessary?
> see above: I think so.
>> How hard is it really to keep filenames and directory locations for a 
>> selected group of public resources?
> no, that's not the issue: the real issue is: if both resources and 
> pipeline outputs are streams, why make a difference?

Ok, there are several thoughts in all the above.  Here they are with 
what is in my mind the state of the discussion:

1) Resource access
"Should resources be provided via pipeline, via standard file i/o, or a 
combination of both?"

I think we now all agree that pipeline-only is the way to go.

2) Resource visibility
"Should some ability to distinguish between public and private 
resources/pipelines exist?"

Yes, and @block-access="public" handles this well presuming that 
discussion can be considered settled. (but see below)

3) Explicit resource uri's
"Should exposed resource (pipeline) uri's be declared explicitly?"

This is where I still have some reservations as begun above in the 
not-found/fallback example.

<map:match pattern="stylesheets/*.xslt">
   <map:read src="styles/{1}.xslt"/>

Is convenient to write, but may be inconvenient to use for block users, 
extenders, implementers, and the BlockManager (code).  Perhaps the first 
  can be taken care of with human readable documentation (though I fear 
what the cocoon blocks will have in this respect).  Perhaps the second 
is unfounded.  I'm not convinced of either of those and think it merits 
further thinking.

A possible solution:
Rather than disallowing wildcards, perhaps a part of block.xml could be


Maybe that'd be a pain but it'd leave no guessing.  Maybe:

<extends block="">

Would be better?  It would get rid of the fallback problem.


View raw message