The year that:

1. Brought us some prove of our pudding: There are business opportunities around the open source vision. Even for smaller entities like ours.
2. Confirmed that running your own business is mainly Hard Work ™
3. Confirmed that the joy of self-control keeps the absolute justifying return of that work.
4. Extended the network of friends, partners and customers well outside the Belgium borders. (Again thx to the Open Source Factor)
5. Made me an Apache Cocoon committer, still very proud.
6. Guided Apache Cocoon into the realm of interactive applications. And in all modesty I think we have been playing our part of that game. Now the first half of 2004 should shape up. Stay tuned
7. Hosted another succesful Cocoon Gettogether
8. Brought you to this page :-)

Wishing you all, yes you too, the happy eagerness to enjoy 2004. That includes the 'Health, fun and friends' which are the typical prerequisites to get you there...

Over at cocoon-dev Antonio reports about letting the root-jar include an index-file to speed up retrieval of classes in secundary jars.

Another example of Sylvain's mythical third eye... I only knew about using the O-option to gain some run-time by skipping decompression-processing.

Dropped in the box via e-mail: Beyond MVC: A New Look at the Servlet Infrastructure. Just some days after making public some of my own views...

And I'm really sold before it even begins:

...my goal with these two articles is to convince the servlet middleware community once and for all to put the dark days of MVC behind us and to lay the groundwork for completely new, nonderivative servlet middleware architectures that better address our common needs...

After reading it:

• Very well written.
• Interesting (historic placement, well argumented) and thought provoking (I like looking through other people's telescopes)
• Nothing less then a must read.
• Still, I'm disapointed enough at this time to be impatiently waiting for the second part :-) So what am I missing:
• Where is the role of the URI in dynamic web apps? (some lessons from ReST?)
• Why not holding on to the Business-Modelling relevance of the C in the MVC approach: realize a 1-1 mapping between the Analists' UseCases and the coded Controllers. The biggest challenge IMHO offered by the stateless nature of the web, is to re-create this logical spot to technically encode the clear sequential user-system interaction-scenario as written down in the UseCase.
• Why so easily going by at the presentation problem? At Javapolis I saw Craig McClanahan tell about JSF: "this stuff is view only, we're not looking into controller issues ATM". In this story I see the other extreme and I really think we should take a more holistic approach first. (That is in fact another lesson to learn from classic MVC, no?) Don't get me wrong. We do need sound SoC. But you can NOT get there by ignoring those concerns you don't like in the picture. So while not wanting to (sic) 'replicate those extremely advanced presentation techniques' the current approach very much lacks the contract to integrate those.
• I guess my disapointment should go away after taking some more time and actually getting into the nuts and bolts of this shocks thingy

Meanwhile I'm left to wonder if this article will really set the bomb under this overdue web-MVC-mantra. Given my earliest posting on this topic last year (almost the very day even) I'm sure I'm ready to wait some longer :-)

During a pleasant chit-chat-chat with color-loving mama Mosh I received this reference to ColorMatch. (Warning: IE only)

Did you also see this GoogleBomb fly by recently? Apparetly some peeps have been succesfully assigning a new meaning to the term 'miserable failure'.

One of the articles about the funny event mentioned that it really is quite easy to mislead Google in this way... It was said to only take some 25 links and *BOOM!* there you go... But hey: 20+ ? That sounds still like some work and hoping for people to participate in your effort... And sure enough there is an easier way!

Consider this quite unique discription I recently used in the subject of a posting on the cocoon-dev list. Some replies in the thread and with the help of the numerous mail-list archiving systems hapilly indexed by dear friend Google... and guess what: I singlehandedly helped Google define the term 'Cubist webapp team' ?

I'm in doubth now: does this chain of consequences make me a GoogleTerrorist?

Just so we can do it on purpose now, let me refer to this blog-entry with the term GoogleTerrorist. You can check the effects here.

Posting the previous entry made me realize I haven't blogged yet on the JavaPolis thingy last week. Here is my list of refreshing thoughts/hints initiated by one or the other:

• During a short corridor talk with Craig we contemplated the introduction of some new JSP-'scope' that we defined largely as bigger then a request, but smaller then a session. He called it TranscationScope while I refered to it as InteractionScope. This probably depends from your viewpoint, or else is hiding that there should be two :-)
• Jacek's work of the last 20 months is more then just impressive. I knew this already after XMLEurope this year, but then I missed his presentation. Seeing that I also got to see he 'en passant' came to define some efficient binary-compressed DOM (XML Infoset) format.
• Inside XMLBeans is a Cursor API that kinda looks like JSR173 and should guarantee some very flexible and high performant parsing.
• Apache JMeter has a proxy to record the URL-interaction to be re-run during test.
• A full presentation on it left me with the conviction that this is an enteresting book.
• During after-polis dinner Jacek made me swear I was going to read this as well.
• AOP is happening, together with the micro-container thingy I see how the EJB zealots are finally being confronted with the fact that the strict-EJB-mantra is maybe not going to make them completely happy after all.
• Stale and Scale. The web works well on large scale because proxy intermediates allow introduction of stale information. A pretty ReSTy observation to make IMHO.
• Any programming task that requires 100years of compuyting can be done in 14years of which the first 13 are about hanging out at the beach :-)
• Oracle still doesn't have a clue. -- The kenyote slot they got (or bought?) was the worst I've seen since ever. Utter waste of time.

I recently saw Adam active at Javapolis 2003. His talk was very thought provoking. (As predicted by dear friend Jacek who's talk over there was also quite appealing to some higher processing cycles...

In any case, Adam now plays the innocent newbie on the ReST topic and naturally succeeds to arrange some gathering around his reflections. Be sure to read up on the Comments!

Looks like the conference in Philly will gather some wild thinking folks.

Bertrand picks up a thread on cocoon-users... Here is my 2c

Anecdote: Some time ago I was being so utterly proud of a complex stylesheet (I seldom do this) I wrote. When presenting it to the local XSLT-guru I was told that the thing was utterly unreadable, and thus utterly flawed. This dispite the fact that it might have been working of course. Yeah, we tend to believe that it's not WellDone(tm) just because ItWorks(tm). The nice observation however was that he just simply rewrote the XSLT to solve the same problem (and I have to admit in a fraction of the time spent). But that is just what he did: he re-wrote the thing. Not looking at different variable names and such, Steven just produced the exact same XSLT solution, of which I could only testify that it was indeed utterly unreadable. ;-)

Since then we know that the biggest pitfall of the language is that it realy is a WRITE-ONLY language. (Meaning: never meant to be read by humans, including the author)...

I 'm sure the thread over at Bertrands' will give us new insights on what is the cause of this... Most likely will offer some interesting reads, but at the end of the day we'll just need to be brave and learn to live with this great technology?

I've been working out a new presentation in the area of web-apps. And have dry-run tested it in short version speaches last weeks already here and here.

The four points it is trying to get accross:

1. The main indicating attribute (and the one that is ever recurring in any type) of the HTTP request is the request-URI. Since it has interface value, one needs to do a proper URI-request-space design. (In Cocoon speak: write a sitemap)
2. The returned response format on the other hand can be anything served on the menu of the day. Selected use of common patterns (see Martin Fowler) like TemplateView, TransformerView, TwoStepView will only get you so far to produce all similar and different outputs in a way that ensures some componentized reuse in the publishing. One needs to be able to (un-)plug(-in) all those design techniques at will in a componentized publication pipeline. One could use the binary-stream oriented pipeline components that were introduced by servlet filters... However the easy wins in using the semi-structured SAX-pipelines from Cocoon will easily get you addicted. And don't ignore that you have XML on the wishlist anyway.
3. The stateless behaviour of the web has kept on tantalizing web-development. Despite the many proclaimed MVC for the web frameworks we are still out of reach off the true benefit of that classic GUI pattern: create a spot where one can isolate the procedural control of the interaction, as it was written down in the use case? If you find this a bit misty as a description, well just check out Cocoon's flowscript based on Javascript continuations, you're bound to get one more addiction.
4. Finally, these interactive web-apps tend to be running around the issue of presenting and processing forms. Some experience in multi-skilled web development teams lead me to believe that the two sure ways to failure here are (1) having a strict web-design-driven approach (wow-looks, doesn't work) or (2) having a strict back-end-driven approach (dull looking, unusable but essentially working). The way to success here seems to be the cliche of communication and symbiosis of both worlds. In art-terms I call this: taking the 'cubist view': mapping the different viewpoints onto one painting. In technical terms it is about introducing a central form-model that holds both all required info to serve and handle good looking, usable forms as well as all information to keep the back-end happy and operational. Oh, just to make sure I'm not leaving you wondering: Cocoon currently is hosting a Form Framework that does this.

Rephrased, these four items kinda sound like: Cocoon, Cocoon, Cocoon, Cocoon. But seriously, they do seem to appeal to a broad common sense in such a way that in both occasions I've genuinly see them hit the audience with the impact of a gentle sledgehammer. Well, none of the above tries to claim eternal truth but presents itself rather as a fair set of observations.

In any case, obeying the intellectual honesty attitude over at Apache Cocoon: *WDYT? *

In annual tradition, we went to see Sinterklaas arrive at the Twins-club yesterday.

Our Tuur (age 3,5y) proved to be bravely outspoken (and thus utterly funny) when in speaking distance of the microphone. Odd how he can be so nervous upfront of *big* events like this (e.g like last month's grandparent-school-theatre thing) but then when the time is there, he's able to leave it all behind and be his most natural self.

Fien (age 5y) just insisted on being her silently charming self, more busy with looking after and making sure little bro' didn't completely loose himself. Boy they are getting big.