What an evening. I've been copying the 700+ MB which holds my Mozilla profile back and forth for several times, and am now running the 1.3 bèta version to get rid of some other post-rescue issues, so I'm betting on more fun coming up ahead. All in all, it looks like 1.3 is a bit snappier than the 1.2 I had running for quite some time, so hopefully they'll move out of beta soon and I can get on with my life.
Which means I'm desperately trying to get a grip on my steadily incoming mail queue, while browsing some interesting thread on community at apache.org on the creation of a jar repository. Lots of stuff is kinda happening these days in Apache-land, more on a community- and open-source-sociology-level than in terms of hard code and projects. In various little ways, the not-so-newly-elected board is making its difference. Flattening project hierarchies, mass-nomination of PMC members, trying to make projects less dependent on the board's wisdom, while keeping a grip on stuff going on...: it's only after quite some time that the difference in style and focus is becoming obvious. Some people like this, other don't. Fun to watch, even more fun to actually participate in some of it.
The circle of Apache people is growing again, and this time it's a special one. Bruno just got proposed as a Cocoon committer, and has been voted upon with an abundance of +1's. Which means that a) yes, Outerthought is staffed exclusively with Apache committers (there's no company like that in Belgium, but admittedly being only with 3 makes comparison quite difficult), and b) the challenge lays again in front of us. Congrats to Bruno, of course.

Much to my dismal, computers and I didn't go along well today. When installing Forrest at one of our customers, I spend many messy hours discovering the difficult relationship between a certain new Linux kernel and the Tomcat Java code (java -version went well, but booting up Tomcat was greeted by much silence and some blockage only to be discovered by strace). XXE still blows my newly updated Sun JDK into a W2K BSOD (!!) when shutting down. And while BSOD'ing, it took down Mozilla in an uncomforting way, shredding my profile into oblivion to be rescued only by a rather painful and manual rescue operation.
I didn't lose any mail in the process (I think), but it will take me some time to get back to normal operations. Who said computers help us to be more productive? Not. :-(

Tonight, there was the (late) 2003 working year kick-off meeting of the BeLux XML user's group I'm participating in. We've got a line-up of 6 planned events for this year, and no conference as we did the other years. People seem to like short half-day focussed events better than day-long group gatherings with speeches and all. If all goes well, we'll get Mike again, now about XQuery, and possibly Dave, too.
This afternoon, we had a prospective meeting with some guy working in business intelligence and data warehousing (which we don't know sh*t about, but want to learn because of xReporter). The meeting wasn't exactly a success, except for the nice and open discussion, which taught me something about open source and how it will get us rid of intermediaries. We thought the guy was a consultant, but he was refocusing his line of business more towards software distribution this year. So we were basically trying to come up with a business model for distributors of open source software. For a one-man company like his, he said selling 4 copies of a certain (proprietary and expensive) software tool meant breaking even for a year because of the margin he got on the license sale. Any extra services on top of a software sale was money in the pocket. He also stated the average cost of 15% licenses on a large project wasn't big enough so that IT managers would change their perspective on open source just for budgetary reasons. They might be doing that for brand awareness reasons, and that was what a distributor could help you with.
Needless to say, doing this with open source tools is more of a problem... If people need services around xReporter, they are more likely to come and talk to us. And because xReporter is open source, they are not required to come and talk to anyone anyhow. In any case, we felt it was quite 'difficult' to agree on a margin for him, calculated on a license cost of zero. And he had no time to invest in learning to use xReporter so that he could sell its own services around it. Does that mean open source is the end of all intermediaries?

When people come and ask me again whether MS has any clue about open source, I'm going to refer them here. Simon is one of the most-mildmannered keynote speakers I've ever seen. I'll never rememberforget that he was very much willing to come and see us when I helped organizing a local Java/XML event in 2000, even if the audience was fairly small.

Visitors from Germany. Some other countries are expected, too.

I think I won an award today. I installed the ugliest mailing list archive in the world. Gee. :-)

I have three new cocoondev.org-hosted initiatives in my backlog for tomorrow: Luca's JFreeChartTransformer, Geoid for a hatching GIS-on-Cocoon initiative, and a Cocoon webmail showcase. It's nice to see so many new things getting started around Cocoon. Today, I did an XSLT seminar, and also showcased Cocoon. People looked very interested, even after being brain-stuffed all day long with XSLT basics and the not-so-trivial wonders of the XPath data model. Next, I need to write up my paper for XML Europe. I also sent in a proposal for the NLUUG Spring conference on 22/May, trying to spread the Cocoon word as much as possible. Next week will be a very intense Cocoon-related week, hopefully with a good outcome. And the week thereafter, we get to install Forrest at one of our customers, so I'll need to get up to speed with what has been happening during the last few weeks.
Besides, I'm thinking of how I can let the Wiki and Cocoon play nice together, and I have a vague 'copious free time' intention to try adding some Forrest migration targets to the Cocoon build. It's about time Cocoon starts using Forrest, but the amount of information is that huge, that nobody dares to just do it.

Of course, if you are the world's leading application infrastructure software company with more than 13,000 customers around the world, that doesn't necessarely mean people will listen to you when you speak up. Even better, industry luminaries might as well be totally underwhelmed with your precious pet peeve. A breakthrough technology, hoo hum. Even more interesting is the question what this has to do with JSR-31, which has been recently voted upon and should (finally!) be released to the masses.

Sleepycat has just announced a new Release Candidate of its (in my book) much awaited XML database engine. It now also features a Python API, Perl and Ruby being in the works, and Java/C++ for real programmers. Yummy stuff.

After the grouping stuff, we have been adding a new skinning subsystem into xReporter, so that people can more easily configure xReporter to their visual liking. Through xsl:import and some clever compartmentalization of our stylesheets, we still manage to keep the amount of XSLT transformations, which require to build a tree out of the SAX events being passed across the Cocoon pipelines, to 1 (one). Also, we go at lengths trying to keep the sitemap as simple as possible, mapping logically onto URI space. Even Cocoon haters should be appreciate the conciseness of this little snippet which shows an (optionally chunked) report to the end-user:

<map:match pattern="*/reports/*/output">
  <map:act type="determine-chunk">
    <map:act type="xreporter-request">
      <map:parameter name="lang" value="{../1}"/>
      <map:parameter name="path" value="/reports/{../2}/output"/>
      <map:parameter name="method" value="GET"/>
      <map:parameter name="parameter_chunkOffset" value="{chunkOffset}"/>
      <map:parameter name="parameter_chunkLength" value="{chunkLength}"/>
      <map:select type="parameter">
        <map:parameter name="parameter-selector-test" value="{result-type}"/>
        <map:when test="LINK">
          <map:call resource="xreporter-link">
            <map:parameter name="lang" value="{../../1}"/>
          </map:call>
        </map:when>
        <map:when test="OK">
          <map:generate type="xreporter"/>
          <map:transform type="include-style-info">
            <map:parameter name="path" value="resources/customlayout/html/"/>
          </map:transform>
          <map:act type="determine-stylesheet">
            <map:parameter name="path" value="resources/customlayout/html/"/>
            <map:parameter name="default" 
            value="resources/skins/{xreporterdefaults:skin}/stylesheets/html/output.xsl"/>
            <map:act type="context-path">
              <map:transform src="{../stylesheet}">
                <map:parameter name="context-path" value="{context-path}"/>
                <map:parameter name="lang" value="{../../../../1}"/>
              </map:transform>
            </map:act>
          </map:act>
          <map:transform type="i18nbackported">
            <parameter name="locale" value="{../../1}"/>
          </map:transform>
          <map:serialize type="html"/>
        </map:when>
        <map:otherwise>
          <map:call resource="xreporter-error">
            <map:parameter name="lang" value="{../../1}"/>
          </map:call>
        </map:otherwise>
      </map:select>
    </map:act>
  </map:act>
</map:match>

How nice. Only days after this.

Belgium. The seat of both the European Union and the NATO. Worldwide top-ranking density of motorways and cable network. Home of Kim Clijsters (3), Justine Henin (4), famous beer, Tin-Tin and chocolate. Anyway, never mind: these were just some things to still remember about us once today has faded away in memory. Nice one, Michel.

Once in a while, Dilbert is plain hilarious.

Whee. :-)

The W3C Quality Assurance Team has posted two useful notes on Common User Agent Problems and Common HTTP Implementation Problems. The former should required reading for anyone attempting to write a browser. In particular, the IE team at Microsoft really needs to read this, though they're hardly the only group out there that can benefit.

The second note should be read by anyone attempting to write a web server of any kind, whether a traditional web server like Apache, or some sort of application server like WebObjects. In particular, the section on URIs is required reading for Apple's web team, the WebObjects developers, and all the subscribers to the webobjects-talk mailing list who just noticed that I called their favorite software a piece of animal feces back in October (Actually, I was more polite than that, but I shouldn't have been.) and who persist in bombarding me with e-mails that only prove that they really don't understand HTTP. Here are a few clues for the clueless:

• All URLs should be able to be bookmarked and linked to.
• HTTP is stateless by design.
• The difference between GET and POST has nothing to do with how many characters broken browsers can stuff into a URL.
• Cookies are unnecessary for user authentication, shopping carts, or anything else.

Yes, more developers and more software operate the wrong way than the right way. This includes WebObjects, though it's hardly alone here. There are many other broken sites and broken software that behave similarly. Good library software is implemented by experts who really know their field. The software does the right thing so the developers who use it don't have to be experts in the field. WebObjects is not good software. It was obviously designed by programmers who were not HTTP experts. They may have known a lot of things about GUI design, databases, programmer productivity, and the like; but they didn't know HTTP. Consequently, they made a lot of novice mistakes that are now propagated by almost every web designer using WebObjects. WebObjects makes it easy to do the wrong thing.

If you want to argue that the Web architecture is a bad architecture, that HTTP should allow state, that unbookmarkable URLs are a good idea, and so forth, feel free; but first you have to understand what you're arguing against. Do the necessary homework to understand what the web architecture you're arguing against is (and of course whether you really want to be arguing against it in the first place). Otherwise you end looking as foolish to people who do understand the web architecture as the early 20th century etiquette books that suggested you write a letter to people you wanted to call on the phone to find out when would be the appropriate time to call look to someone who actually understands the phone system.
[from Cafe con Leche XML News and Resources]

Cool. Some conclusions, remarks and chest-thumping:

• We've done a good job when designing xReporter. As a result, our URIs are bookmarkable, since no cookies have been used and no ugly session id is being communicated using URLs or (bah) hidden form fields. People can easily mail links to report instances to each other, even mid-flow if they want - no state in our URIs. Authentication and authorization are handled by the container, and not embedded in the application.
• I invite people to take a look at how we manage flow in our application. The flow is controlled by the back-end, but is communicated quite ingeniously to our Cocoon pipelines - simply stating OK, which resource should be LINKed to reach the next step in the flow, and so on.
• Elliotte should make sure his individual news items are bookmarkable, too. I badly need an RSS feed of his news site. :-)

• 17:00 - Carsten goes off to home, frustrated with the little amount of work he got done that day.
• 19:00 - Arriving home, he cranks up his laptop, and gets to work, off-line.
• xx:xx - Happy with what he has done, he goes to sleep.
• 07:00 - Carsten raises, washes and brushes and goes to work.
• 08:00 - Arriving at the office, boots up his laptop, and does the morning cvs commit. People of the earth: rejoice.
• 09:00 - After reading the morning mail, his colleagues start to ask him questions. And questions. Oh boy, lot's of questions.
• 11:00 - He finally gets back to his laptop, and is able to work on some little code patches.
• 12:30 - Lunch. Colleagues ask questions. Carsten starts to worry about the amount of actual work he will get done that day.
• Afternoon - the US wakes up, RSS feeds to read. Answering user questions on the mailing list. Matthew starts asking questions. Carsten starts to accumulate his todo list for the evening. Some commits, but not nearly enough.
• 17:00 - slightly frustrated, he shuts down his laptop and goes back home.
• 19:00 - Arriving home, he cranks up his laptop, and gets to work, off-line ...
• ... repeat ad nauseam :-)
  

Update: Hm. It looks like my perceived reality was wrong. Carsten hits the office early in the morning. And he never works at home. They'd better buy him a laptop ;-)

Just curious... am I the only one who believes the author of the IBM developerWorks newsletter is a real-life reincarnation of Ted, the generic guy? It looks like the developerWorks editorial team also works from the RTP area, so maybe I should ask Sam to provide Robin with some genuine wit for the newsletter's editorial intro. Being colleagues, that shouldn't be to hard. Lately, the editions of the dW newsletter were introduced by Robin with musings about:

• Lacrosse
• Cribbage
• Vacuuming broccoli
• Snow
• The compost heap
• Snow again
• Door decoration
• Stairways to Heaven
• Cream and sugar
• The office costume party
• ....

and various other strange topics for a technology newsletter. Sorry Robin, but are you on dope or what? ;-)

• 15:30 GMT+1: somebody asks for tutorial information about Cocoon on the users mailing list
• 16:00 GMT+1: Irv from Dotech says he wants to send some PDFs to the list, but they are too large
• 16:53 GMT+1: Irv sent them to me, they are now up on the Wiki.

Nice one, Irv!

I just posted the first edition of the xReporter Community Babble to the mailing list. Read below!

               xReporter community babble, first edition
                    http://xreporter.cocoondev.org/

Dear early adopters,

I hope all your first steps with xReporter are going well.

Some little background info news tidbits:

- We are currently 25 on the mailinglist. Do not hesitate to
speak up!

- In January, we had slightly over 1200 downloads, and a lot of
visitors to the website. This partly because of the extensive
linkage from busy websites such as The Serverside, Freshmeat and
OSDir.com.

- We added grouping capabilities (and isolated the grouping
component into a standalone Cocoon component, too), all available
from CVS.

- As you just have read from Bruno, we will be working on the
'skinning' of xReporter, so that it becomes easier to create your
own look&feel for xReporter. A sample skin will be included.

- Expect a 1.1 release of xReporter when this is finished
(somewhere by the end of this month).

- We are working on an XML.com article about some design ideas
behind xReporter, hopefully stirring up even more interest on
xReporter.

- We have just ordered raw database material (Belgian election
results), which will be used to spice up the live demo on our
website.

Also, we will be present at the ITWorks Data Warehousing
Solutions Expo (http://www.itworks.be/DWSolutionsExpo.html) on
2-3/Apr 2003 in Brussels, Belgium.

Expect to hear more about new charting capabilities, too. That's
about it for now, we'd love to hear from you! Do not hesitate to
contact us with ideas, bugs, patches or anything else you want to
share.

Best regards,

</Steven>

There is a lot of turbulence lately on the Apache mailing lists about what non-ASL-licensed libraries can be used and redistributed without breaking the rules laid out in the respective licenses and the general ASF policy, or invalidating the rights of people who want to redistribute ASF software that makes use of such libraries. There is special concern with regards to (L)GPL and Sun-licensed libraries. Clearly, one of the (willingly?) unresolved issues concerning the LGPL license is the definition of linking, which basically means LGPL library interfaces cannot be easily be used nor redistributed by ASF software. Also, some binary Sun licenses are becoming a no-go area until Sun explicitly states what they are up to. While open source license discussions are by definition an arcane science, a nice overview (albeith not an official ASF policy document) has appeared on the Apache Wiki.
One thing I learned out of this discussion is that the ASF cares a lot about the ultimate freedom of people wanting to distribute software based on ASF software. Pretty clueful. The idea behind this is that people should be able to do whatever they want with ASF software, as long as it is properly credited, without the risk of breaking the license rules of non-ASF libraries used by these ASF projects. Another good thing emerging from this discussion is a variety of proposals with regards to package distribution and dependency checking. Hopefully, this will result into the creation of a CPAN- or FreeBSD ports style of central library repository, inspired by the Maven, Centipede Ruper and JJAR projects, eradicating the jar-hell we all have to deal with. Cocoon, which ATM has 81 (!) library jars in its CVS repository, would be a prime candidate for such a setup.

Ugo Cei: I'm sure that, coming from Outerthought, it's a great piece of work. Kudos to Bruno. Yay!

Problems with grouping and XSLT inside Cocoon? Rescue is on its way! If you are using Cocoon and its SQLTransformer (or some other mechanism to inject tabular data into your pipeline), and if you want to group the rows in these tables and also summarize them (making totals and the like), I'm pretty sure you were already confronted with the arcane theories of using xsl:key and friends in order to circumvent serious performance penalties - multi-level grouping being even worse. Since we needed grouping inside xReporter, and it turned out to be easily repackaged into a stand-alone Cocoon transformer, Bruno went off and did so. Enjoy.

Ben, Santiago and Dirk have been working on a little mapping application that uses data embedded in Apache developer's webpages to draw a geo-distribution map. Here's a snapshot of the European situation so far:


Click on the image for a live update (and be sure to mess around with the request parameters to see your part of the world! ;-)

Candidate Pythonistas might have a look at this Python tutorial-in-progress.

xReporter now supports grouping (in CVS), which was an often-requested feature. It's nice to see so many good comments on the mailing list. It appears the installation procedure isn't as daunting as we thought, and people are surprised with the amount of features and configurability offered. The demo looks pretty dull, but once you scratched the surface, it's really quite feature-complete: internationalization, look&feel customization, security and authentication stuff are all there. I've been on the phone with some people from DataDirect, hopefully we'll get to present xReporter to them and some other database vendors.
We don't offer a fancy report designer, though. But then again, any XML editor will do. We'll need some business based on xReporter before doing the quantum leap of doing a GUI.