cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Starting 2.2
Date Tue, 19 Aug 2003 17:06:25 GMT

On Wednesday, Aug 13, 2003, at 22:04 Europe/Rome, Tony Collen wrote:

> Joerg Heinicke wrote:
>> Stefano:
>> "the road to real blocks: how to build it minimizing the impact on
>> the existing code and with complete back compatibility (yes, it's
>> possible!)"
> Here's my own Mini-RT:
> If you've used a BSD, you've quite possibly run into what's known as 
> _ports_.  Ports is really cool, and for anyone who doesn't know what 
> it is, here's a little description.

Yes. BSD ports or Debian APT has been influencing the design of blocks 
since day one.

> Ports is a big directory skeleton which usually sits in /usr/ports.  
> It is organized in a hierarchy, so you end up with a directory 
> structure like /usr/ports/games, /usr/ports/mail, /usr/ports/irc, etc.

I strongly dislike the taxonomy approach. Because finding agreement on 
where to place a block will be hard in several cases. But this is an 
issue that will be addressed by the block librarian.

> Under each category is another directory for each program which 
> belongs to it, so /usr/ports/games/fortune, etc.  Now the cool thing 
> is that each program directory contains a makefile, unified diffs, and 
> a list of repositories where the software resides. (FTP, WWW, etc)

I have presented a much more abstract way of achiving the same 
functionality using pluggable locators and non-locating identifiers.

> When you run make, it automatically downloads the software from the 
> repository, and patches the software specifically for BSD.  Even 
> cooler, is that it automatically takes care of dependencies 
> recursively.  Once all the dependencies are done, the software is 
> built.  There are several other commands, such as "make install" or 
> "make clean" which does the usual expected chores.

We (luckily!) don't need all this. java can be shipped precompiled and 
blocks will be configured by the block deployer.

> The only downfall is that you have to keep the directory skeleton up 
> to date.  FreeBSD does this over CVS.   Very handy.

Handy, but painful because it mixes concerns between cataloging and 
location. We should avoid this.

> Now, imagine this applied to Cocoon and blocks.  If we distributed a 
> "core" Cocoon, we could dramatically cut down the typical amount of 
> code that gets distributed.

absolutely, this is one of the goals.

>   If we wanted the PDF block installed, all we would do is go to 
> $cocoon_src/blocks/pdf/ and type build install.

that would be an improvement on what we have today, but it's poor 
compared to what I want to achieve with blocks (see my latest RT on 

>  It would download the PDFSerializer, and realize that the FOP jars 
> are required, and download them.   We could also come up with some 
> "block packages" that are geared towards some basic tasks, i.e. blocks 
> which are grouped together to accomplish some goal.. sort of how the 
> more popular Linux distros have a "workstation", "server", "basic", 
> "everything" install.

Yes, "block bundles" will be available and will be the preferred way of 
downloading complex software (say forrest, linotype or lenya) on top of 

> That's my RT, I hope I didn't spoil anything anybody was saving :)

Not at all. Thanks much for the info, but everything you want will be 
there and much more ;-)


View raw message