I've just send the design for an Outerthought T-shirt to the printer. During the Cocoon GetTogether, we will provide food, drinks and clothing to the people of Cocoonia - we must be Samaritans :-D

No, no Cocoon logo on it, just our logo and byline.

Yep. It has finally happened, even in conservative Europe. I must get my old copy out of my bookshelf and dusted. Due to email lists, instant messaging, weblogs and other tribal communication tools, it is sometimes easier to understand what is going on in a company than when viewed from the inside. The cubicle walls are apparently higher than the headquarter's skyscraper walls.

Thanks to the dotcom boom, people also realize there is no silver bullet. It's just work that has to be done, and I believe working inside and together with a community is much more fun and spiritualizing than trying to productize and sell everything.

Update: Matthew argues this can be a hard sell. If the business case allows us, we just provide the customer with a reduction if he is willing to release the code afterwards. Financial arguments always help. Also, we give him continuous access to the project, but only using "open source" methods: mailing lists with CVS commit messages, and the necessary knowledge for grabbing the sources and building/running them locally. They don't do patches right now, but even after some complaints in the beginning, it seems they are pretty happy with this way of working. After all, they happen to see how much work you put in the project on a daily basis.

Big grin - my baby daughter just finished her bottle. The two boys went to bed hours ago, but she prefers to enjoy the evening hours, it seems. I wonder where she got that from?

Ovidiu asked me to elaborate on the statement of <map:aggregate> considered harmful, so here goes...

When I started to use Cocoon, I made extensive use of the aggregation component since it seemed like a good way to combine several sources into one output stream. Problem however is that the aggregator is merily a concatenator, i.e. it appends the result of one or more pipelines to another one, provides a root element and fires of SAX events to the next component. It took me a while (and Bruno's help) to find out that this is not what I typically want - the Cocoon aggregator is often regarded as being Frames on Steroids. But I don't want to have one <frameset> document, I want <iframe>'s or even better XInclude!

The problem

A typical pipeline using aggregation does the following:

  --- (T) --- A ---\
                    > aggregation ---> C --(T)--> D
  --- (T) --- B ---/

Let's imagine the 'classic' example of assembling a webpage - we have content and navigation brought together using aggregation. So we will have one pipeline A producing the content (maybe just a FileGenerator, but it could as well be a DocBook2xdocs transformation), and one pipeline B producing the navigation, probably accessing a directory structure, a database or whatelse. With the ideas of the TwoStepView pattern in mind, we won't immediatelly produce (X)HTML yet, we will do that in a final step. So using the aggregator, those two sources are concatenated, and the result is one big document C containing everything we need...

But now, we have a problem: we have to write a stylesheet that translates C into decent (X)HTML D. While this shouldn't be a problem, it causes however a mix of concern I find counterproductive, especially in terms of maintenance afterwards. The stylesheet needs to achieve two tasks: moving the two streams around so that they are correctly positioned in the pagegrid (presumably) constructed using an (X)HTML table, and doing the style transformation of the individual elements from XML to (X)HTML.

Getting there? No.

Thinking I could do better, I started building two-step transformations inside pipelines A and B, making sure that (X)HTML was sent into the aggregator. And yes, my last transformation became much simpler, basically only positioning elements into an HTML grid. I thought. Because it still felt not right. My final post-aggregation stylesheet still contained (X)HTML-generating templates in non-obvious places.

The CInclude Transformer

To have your pagegrid properly split out from the various components it is filled with, the CInclude transformer seems like a better solution. Your input document to the CInclude transformer will basically be structured as your pagegrid table. If you would be generating portal-like pages, you might as well have a <grid> with <pane>s in it, too. These panes are then filled (should we say 'decorated'?) with (X)HTML fragments coming from the different content- or navigation-producing pipelines, perhaps parametrized with respect to what kind of (X)HTML markup they should be producing using simple sitemap parameters.

That stream is passed into the CInclude transformer, filling up the panes, and presto, the only (X)HTML manipulation which might be left is producing the <head> element and wrapping the stream with the appropriate <html> element. Nothing fancy - something which could be hardcoded in the input document to the CInclude tranformer if you have only one type of lay-out to generate.

The funny thing is that the CInclude tranformer input document will likely to be dynamic, depending on the URI request. So you'll have a stylesheet building up that input document based on external parameters. Basically, you could get rid of the input document to that transformation, because the result of the transformation can be completely artificially constructed, without an input document directing the process. One could imagine a NullGenerator for producing such documents, don't we?

The result

  --- A  ------------
                    |
  --- B  -------    |
               |    |
               v    v
  --> C ----- CInclude
                  |
                  v
               (X)HTML

Comments are welcome!

Yesterday, I had the occasion of being invited to an 'Oracle on Linux' diner organized because some Oracle R&D people were (supposed to be) in Belgium. While I'm not a Linux nor a database afficionado (this stuff is 'merily' infrastructural to me), the gathering itself was interesting because I had the opportunity to meet some ardent Belgian {GNU/}Linux supporters.

I had the opportunity to reiterate the license debate we had on the cocoondev.org list with Peter Vandenabeele, CEO of a company working on embedded Linux implementations. He is also working on the thin balance between free software, community, and keeping a business sound and safe. Interesting guy to meet.

Reminder to self: Bruno and I talked about aggregation versus cinclude inside Cocoon. Seems like a nice Cocoon best practics topic to elaborate on.

Strange: apparently work has continued on dbXML v2, parallel to Apache Xindice which has been kind of languishing since it has been donated to Apache. Or at least that is what I can make up from Tom Bradford's homepage. Fork is a fact of life in an open source context, but it seems Xindice has been an example of graveyard dumping. It works, actually it works quite well, but I haven't seen major advances being made since it has been donated. Perhaps developing database engines is rocket science after all, i.e. not suited for OSS.

Phfew... After lenghty talk (the Unix alternative to IM!) sessions with Dan from AO, everything is more or less set up and waiting to be populated. Together with Dan, I moved the old outerthought.org website running a pre-2.0 version of Cocoon into a shiny new Tomcat 4.0.3 JVM and Cocoon 2.0.3, and prepared some other things so that we can now start to really build cocoondev.org.

Side-effect of this massive transition is being cut off from mail for some hours to a day. Hopefully I won't be de-listed from too many email lists because of some bounces that are bound to happen, and not too many get frustrated by our little mailing lists not being up right now.

All-in-all, everything went well, no nasty surprises and such. Kudos to Dan and Klay for that!

We (AO and myself) are in the process of setting up the cocoondev.org server. Shameless plug: if you are on the lookout of a really skilled Java hosting company, go see them.

Unfortunately, no content yet - but we'll work on that.

Great news: Ovidiu will be coming over for the Cocoon GetTogether. Mr. Flow in person. I'm getting the slight feeling this is getting out of hand. We have now people coming from Belgium (obviously), the Netherlands, Germany, the UK, France, Italy and the US. Note to self: must find more sponsors.

Ovidiu does a write-up on his position in the cocoondev.org license debate, held these last few days at cocoondev@outerthought.org. As far as I understand, he cares a lot about companies hijacking OSS projects, re-releasing them inside commercial projects/products.

Me for myself I don't care that much. I don't expect to make a lot of money on my modest open source contributions, or at least on the 'code' part of them. If my time working on open source is already supported somehow by my customers, and I get to explain them it is for the better of both of us, I don't care too much about what will happen ultimately with the codebase. Succesful open source projects might have more to do with community rather than code. And hijacking a community is a lot harder.

But maybe this has something to do with my firm unbelief with regards to products. I used to be very product-minded, silver bullet et al. Nowadays, I believe there is more value hidden inside a project, i.e. when people work together to create a solution. Shrink-wrapped miracles-in-boxes might promise a lot, but often prove to be really hard to implement.

Ah - a first rant. Howcome people think they are able to do exotic things with Cocoon without actually coding Java? I'm very afraid to see lots of people using the SourceWritingTransformer and clever sitemap tricks underneath their home-brewn CMS. It is as if many years of worrying about concurrency, fail-over and robustness have been forgotten when one encounters the Cocoon sitemap.

Cocoon GetTogether: so far, 27 people have registered for the event, ourselves and speakers not counted. Still two months to go, and several others that promised to come but simply haven't registered yet, which means the idealistic target of 50 attendees will easily be reached, IMHO. That is soooo cool :-)

Trying to restart blogging. The itch of telling people what I'm up to had not subsided over the past few months, in fact, it would have been easier to use this instead of leaving hints and tidbits in the various mailing lists I'm subscribed to.

Now if only not so many new features were added to Radio Userland in these past few months ;-)