On Wednesday, Aug 13, 2003, at 22:04 Europe/Rome, Tony Collen wrote:
Joerg Heinicke wrote:http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106077110314347&w=2 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 this)
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 cocoon.
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 ;-)
-- Stefano.
