Ovidiu Predescu's Weblog

Apache projects to remove author tags

I've recently found that the Apache Cocoon project, and perhaps other projects too, are going to remove @author tags from the source code. There seem to be few reasons for such a move:

• the @author tag tells who wrote the skeleton of the code first, and not who contributed further to it, documented it etc.
• the "selling" of ASF-branded code is impeded by @author tags present in the code. They do not emphasize the quality control of the community behind that code.
• the apparent lack of legal protection if your name appears as author in the source code.

I strongly believe none of these reasons are valid, and I would be very dissappointed to see such a move happen.

I've contributed a fair amount of code to Free Software Foundation and Apache Foundation, among other free software/open source projects. And it is the first time I hear claims such as those mentioned above.

Over the years, FSF has done a very good job of protecting the software donated to it. FSF, just like Apache, requires contributors to assign the copyright to their work to the Foundation. From that moment all the legal claims are handled by FSF automatically, and the author is fully protected from whatever legal threats. The third argument above makes no sense to me. I don't see how removing the @author tags will prevent this from happening. It's not like the software appeared in CVS by magic: some person committed it, whether the @author tag documents it or not.

The history of modifications in a file provides 1) due credit to people writing the code and 2) useful hints on the evolution of a particular piece of code. Take this file as an example. You can see a rough history of an apparently simple, yet very important piece of the GNU Objective-C runtime.

Contrary to the liberal view that community writes the software, I don't think this is the case, at least not initially. Writing software is something very personal which requires not only craft, but also inspiration; it takes time and energy for something to materialize. The process is obviously influenced by a lot of feedback, but in the end is that one individual that writes the initial code. Further improvements of the code also require an understanding of the original ideas, and dedication to improve them. The process is driven by peer recognition and respect; the @author comments document that creation process. Removing them anihilates that recognition.

[Some years ago I was working on implementing a new feature in the GCC Objective-C frontend and runtime library. The initial solution I had in mind needed support of the linker on all the GCC supported platforms and support in libgcc.a, a runtime library distributed by GCC on every platform. I was not sure that was the right thing to do, so I asked on the dev mailing list people's opinion. Nobody was clueful enough to give an authoritative answer, and the original contributors to the code were no longer involved with the code. As a last resort, I asked the original author in a private email his opinion. Sure enough, he replied the next day with his thoughts. After a few other email exchanges, it became clear I needed to think of a different solution. The solution I came up with in the end is machine independent and doesn't require any linker support. Without knowledge of the author and contact information, that would have been a lot more difficult.]

Not having @author tags within comments reminds me of the days working for a large company. You would look at the code alone, with no metadata associated whatsoever, like author tags. If you found a problem or wanted to improved the code, the only way for you to act was to notify the corporation: your manager, some other manager etc., but not the developer himself/herself. People other than developers were in charge and deciding what to do with the code you or your colleague wrote. This ends up promoting an atmosphere were peer recognition is no longer important, and were writing code is no longer the primary focus of a community. For open source software development this would be extremely bad. Open-source software is, above all, about software.

I hope ASF people will seriously reconsider the idea of removing the @author tags.

ApacheCon 2003 slides

I've uploaded the slides for my ApacheCon 2003 session on the Cocoon control flow. The presentation describes the work I've done in Apache Cocoon to use continuations in programming Web applications.

http://www.webweavertech.com/ovidiu/apachecon2003/

I was looking at a similar presentation that I've done in November 2002 at Cocoon GetTogether in Ghent, Belgium, and I noticed with great surprise that all of the items on the todo list were implemented since then. Quite impressive! Especially since all of the items on the todo list were contributed by people other than me ;)

ApacheCon 2003 speaker

I just found from Matthew's and Steven's blogs that ApacheCon is open for registration. It looks like my session on Cocoon control flow was accepted! Carsten, Stefano and Steven have sessions on Cocoon too, which makes things very interesting!

Cocoon flow controller implemented in Java

Alex Krut has an implementation of Cocoon's control flow controller using ATCT - Asynchronous Transfer of Control Threading - a proprietary technology from Velare Technologies that emulates the behavior of continuations in Java.

ATCT's enhanced Java becomes the third language used to implement Cocoon's control flow. The first one was Scheme through the use of SISC; because of the little interest, support for it is not provided anymore in Cocoon. The second language, and currently the main one used in Cocoon, is Christopher Oliver's extended version of Rhino JavaScript, that incorporates continuations support. The Cocoon integration of ATCT appears to be pretty straightforward, the new flow controller simply implements the API provided by Cocoon. Great job, Alex!

The ATCT framework appears to provide the functionality of continuations in pure Java. A similar approach has been provided in Java by Brakes, which instruments the Java bytecodes to be able to capture the state of the execution at any given point in time. I'm not familiar with the way ATCT works, but the Web site claims ATCT is "a patent pending, pure J2SE and J2EE Java framework", which is a dubious statement to me. Continuations have been around for more than three decades, so I really doubt there's anything to be patented here. Anyways, I'd be curious to know more about this technology and what is that the actual patent covers.

J2EE's PetStore with Cocoon's control flow

Christopher Oliver came up with a really nice implementation of J2EE's PetStore application using Cocoon's control flow!

The application controller is written using a modified version of the Rhino JavaScript implementation, that has first-class continuations and tail-call function calls elimination. The application is located here; check out the petstore.js application controller that drives the application, and the PetStoreImp.js that implements the data objects.

The entry points in the application are either top level JavaScript functions, or simply restart a continuation saved previously using the sendPageAndWait function call. Simple, yet very powerful!

Cocoon control flow

It looks like Cocoon control flow based on continuations is gaining admirers and I'm about to be sanctified [1 2 3]!

However I'm not the one that came up with this idea. My good friend Florin Mihaila pointed it out in Christian Queinnec's paper. And Christoper Oliver did an amazing job implementing continuations in Rhino JavaScript. Many other people, including Sylvain Wallez, Michael Melhem, Marcus Crafter, Reinhard Pötz, Stefano Mazzocchi contributed with ideas and code to the current implementation. Thanks all!

The real saint is obviously St IGNUcius (picture). The Church of Emacs even has a hymn, listen to the live recording of it ;)

Cocoon is a top-level Apache project

Pier Fumagalli just announced that Cocoon has become a top-level Apache project! The Web site still needs to be setup, you get an empty page now, but the DNS is working fine. Yupee!

Another Cocoon committer: Michael Melhem

I've just proposed Michael Melhem as a new committer for Cocoon. Michael has done an excellent job with his patch for expiring continuations in the control flow layer.

I was thinking to ask Michael about this last night, but I was too tired and went to bed instead. When I woke up I had an email from Steven who was proposing me the same thing ;)

Jeff Turner as Cocoon committer

Jeff Turner was proposed by Stefano as a Cocoon committer! This is an important recognition of the hard work and commitment Jeff has shown in all the projects he's been working on, Anteater, Forrest and Cocoon. Good job, Jeff!

Control flow gaining popularity

The continuations-based control flow engine, which I implemented for Cocoon on top of Christopher Oliver's modified Rhino JavaScript engine is gaining a lot of popularity.

Miles Elam writes in an email on xml-cocoon-dev:

It's great to see people getting the idea! I've also seen people like Marc Portier delving really deep in the control flow continuations-based code.

I definitely need to find some time and write good documentation on the subject. It should be really useful in spreading the idea.

Matthew Langham: #600

Matthew Langham is number 600 in the list of Apache committers! Congratulations Matthew!

Pictures from Cocoon GetTogether

I've added some more pictures taken at the Cocoon GetTogether, check them out.

JFit: fit your full-blown Java app in J2ME

Sylvain Wallez's J-Fit seems to be an amazing tool. It essentially rewrites the code to remove debugging statements, rewrites the code to work with J2ME which lacks important functionality. Using this tool, Sylvain was able to fit Cocoon in a mere 1.1Mb jar file, and have it running on a PowerPC 50MHz with 32Mb of RAM. Apparently the tools is also very small, about 10 classes each with less than 500 lines of code. All the XSP pages are precompiled, so there's no compilation happening. The result is that requests are served in less than 300ms. This includes time spent by Saxon, the XSLT processor, whose results are not cached at all. With precompiled pipelines, XSLT would no longer be necessary which would speed things up quite a bit.

Hopefully he'll release the tool as open-source, so we can all make benefit from it.

Cocoon thoughts

In this time, I'll try to put together some of the thoughts I have after the very productive and inspiring conversations we had at Cocoon GetTogether. Too bad it was so short and Matthew and Carsten left so quickly. I didn't have time to talk in detail with them, and many of other people. But we did have quite a few beers, which was really good!

I'm very interested in moving forward with few things:

• precompilation of Cocoon pipelines, so that as much as possible is done only once
• automatic expiration of continuations
• identify why my top-of-the-trunk Cocoon installation is so slow, nobody else seems to have this problem
• propose a name change for sendPage as Marcus and Michael suggested, which will hopefully make things clearer.

I'm visiting Bucharest, my home town, for few days. I will be checking my email and blog only scarcely during this time, but I should be back in force on Monday when I get back home.

Cocoon GetTogether wrapup

Marc presented xReporter during which, I'm ashamed to say this, I almost fell asleep. After last night's beers I went to bed at 2am, just to wake up 5 hours later. I think this night will be same, but what the heck, you only get a chance to meet with the Cocoon developers once a year.

Steven and Outerthought have done an amazing job hosting this GetTogether. Many thanks to them for organizing this!

Cocoon talks

Matthew has done a much better job than me describing the talks that happened here, at the Cocoon gettogether.

Steven and Matthew called me the favorite HP employee. I asked him if I'm the only HP employee they know: and apparently I'm not the only one ;)

One bad part about knowing people in person, is that you can't tell when people are just being polite or they really mean it when they say your talk was good.

Torsten is describing various ways you have in Cocoon today to build Web applications. He covers all the existing technologies including flowscript, XForm, precept.

Carsten had a great talk on the authentication and portal framework. Interesting, I've been thinking along the same way but using a control flow approach.

Need to talk some more with Carsten and Sylvain on possible ways to optimize Cocoon, by precompiling pipelines, such that there's no XSLT transformation happening on each request. Too bad Carsten and Matthew are leaving this evening.

Cocoon gettogether

Matthew made his presentation, an introduction to Cocoon. Lots of questions from the audience, ranging from low level stuff to how to use it to build applications for 3G mobile devices.

Sylvain had a great talk on MicroCocoon, a version of Cocoon designed to run on mobile devices. Very interesting work, they built a tool (J-Fit) to dynamically transform the Cocoon Java bytecodes, usually designed to work on full-blown JDKs, to run on PersonalJava, a JDK running on small devices. Lots of interesting things, I hope we'll see these technologies in Cocoon.

Why map:aggregate is harmful

Steven Noels explains the difference between <map:aggregate> and the cinclude transformer in Cocoon when composing aggregated XML documents, like HTML pages for portals. Subtle differences which I didn't realize so far: great stuff, thanks Steven!

The basic difference is in the way the generation of the final aggregated page happens. The <map:aggregate> is a sitemap construct, which essentially places the included XML content from the different source inside some XML elements. Here is an excerpt from Cocoon's samples sitemap entry:

  <map:match pattern="news/aggregate.xml">
   <map:aggregate element="page" ns="http://foo.bar.com/myspace">
     <map:part element="news" ns="http://foo.bar.com/slashdot" src="cocoon:/news/slashdot.xml"/>
     <map:part element="news" ns="http://foo.bar.com/moreover" src="cocoon:/news/moreover.xml"/>
     <map:part element="news" ns="http://foo.bar.com/xmlhack" src="cocoon:/news/xmlhack.xml"/>
    </map:aggregate>
    <map:transform src="stylesheets/news/news.xsl"/>
    <map:serialize/>
   </map:match>

With <map:aggregate> you need to apply an additional transformation step to translate the resulting XML document to (X)HTML.

In contrast cinclude is a transformer which processes a template file with placeholders for the content to be inserted instead. Here's a simple file which could be fed to the cinclude transformer (assume the file is named aggregate.xml):

  <page>
   <title>A Simple Page using Content Aggregation</title>
   <content>
     <para>
      <cinclude:include src="cocoon:/news/slashdot.xml" element="slashdot" ns="http://foo.bar.com/slashdot"/>
     </para>
     <para>
      <cinclude:include src="cocoon:/news/moreover.xml" element="moreover" ns="http://foo.bar.com/moreover"/>
     </para>
     <para>
      <cinclude:include src="cocoon:/news/xmlhack.xml" element="isyndicate" ns="http://foo.bar.com/xmlhack"/>
     </para>
   </content>
  </page>

The equivalent sitemap entry would look like (adapted from Cocoon's samples sitemap):

  <map:match pattern="news/aggregate">
   <map:generate src="file/aggregate.xml"/>
   <map:transform type="cinclude"/>
   <map:transform src="stylesheets/news/news.xsl"/>
   <map:serialize/>
  </map:match>

In the case of the cinclude transformer, we can avoid the last transformation by modifying our aggregate.xml to contain only the necessary (X)HTML html, body, table and/or div elements to give structure to the aggregated XML/XHTML documents.

Cocoon get together again

It looks like after all I'll be present at the Cocoon get together meeting on November 19th. I'll make a presentation of the control flow layer and how it could be used to build applications more easily, using strong separation between business logic, content, presentation and page flows within the application. Obviously I'll make that presentation available online. I also hope to have a realistic demo for it.

Cocoon meeting

Steven Noels of Outerthought officially announced today the Cocoon get together meeting.

I'm still trying to figure out whether I can make it. It should be a very good opportunity to meet face-to-face most of the Cocoon developers, and get some ideas what are people working on.

Model-View-Controller in Cocoon using continuations-based control flow

I've finally had time to finalize some changes to the control flow layer of Cocoon, which should make it more usable. I've also wrote a simple application that makes use of these changes and shows how the control flow layer is supposed to be used. I also plan to write some real documentation on how to use the control flow layer. Before then however, I'll write here some quick thoughts on how this works. At some point I'll take these and transform them into a real document.

JPetStore

Christopher Oliver points out JPetStore, a reimplementation of the classic J2EE PetStore application. Chris is looking at replacing the front-end JSP/Struts implementation of JPetStore with a Cocoon based implementation that uses the control flow engine.

Changes in Cocoon's flow engine

The global space of the variables is no longer shared between users now. Each user has his/her own space for the global variables, and the only way to share information between different users is by means of the servlet API or Cocoon's Environment object.

Another visible change is the fact that scripts now reload as expected when they are modified, when they are declared using the file: protocol. Unfortunately the migration of Source from Cocoon to Avalon (org.apache.avalon.excalibur.source.impl.ResourceSource) broke the reload of the files declared using the resource: protocol. The problem is that the getLastModified() method on the Excalibur ResourceSource always returns 0, instead of checking the timestamp of the real file if possible (see org.apache.avalon.excalibur.source.impl.AbstractSource).

The next thing which I'm working on is to have the JavaScript org.mozilla.javascript.Scriptable object saved in the user' session object, if one is available. This will allow invocations of top level functions (those called using <map:call function="...">) to share the same values of the global variables. This will improve even further the functionality of the whole flow engine, as it will allow applications to invoke top-level functions that implement different parts of the application in the same global scope context, e.g. with the same global variables.

Wish list for a Weblog tool

I've been using MT for more than a week now, and I started to feel some of its limitations. Here's a small wish list for it, or for any other Weblog tool. In particular, I got prompted by Ugo Cei's message on cocoon-dev, to think about working on Cocoblog as the tool to use for my Weblog.

More work on Cocoon's control flow layer

I'm close to finishing the changes I've made in the control flow layer to improve the usability of the whole system.

Java with continuations

Christopher Oliver points out http://www.cs.kuleuven.ac.be/~tim/MOS/brakes.html, a project that does byte-code rewriting using BCEL to implement serialization of Java threads. This could perhaps be used to implement a flow language for Cocoon, similarly with Christopher's version of JavaScript with continuations.