March 22, 2004

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.

Posted by ovidiu at 10:26 PM |

November 19, 2003

ApacheCon 2003 slides

Cocoon | Open Source

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.

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 ;)

Posted by ovidiu at 10:43 PM |

September 15, 2003

ApacheCon 2003 speaker

Cocoon | Open Source
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!

Posted by ovidiu at 11:11 PM |

May 11, 2003

Cocoon flow controller implemented in Java

Cocoon | Java
Water pump - Amsterdam, Netherlands

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.

Posted by ovidiu at 11:18 PM |

March 23, 2003

J2EE's PetStore with Cocoon's control flow

Cocoon | Java

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!

Posted by ovidiu at 11:50 PM |

February 02, 2003

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 ;)

Posted by ovidiu at 10:40 AM |

January 22, 2003

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!

Posted by ovidiu at 11:44 PM |

January 09, 2003

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 ;)

Posted by ovidiu at 10:21 PM |

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!

Posted by ovidiu at 10:02 PM |

December 09, 2002

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:

Cocoon has pulled the rug out from under developers over and over again with great ideas that run contrary to web development norms. Compared to pipelines, the sitemap, actions, etc., flow seems a no-brainer to me. You seem to be obfuscating something that was clear to begin with -- probably more clear than just about any other concept in Cocoon.

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.

Posted by ovidiu at 01:15 PM |

December 05, 2002

Matthew Langham: #600


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

Posted by ovidiu at 11:58 PM |

November 27, 2002

Pictures from Cocoon GetTogether


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

Posted by ovidiu at 03:19 PM |

November 20, 2002

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.

Posted by ovidiu at 05:03 PM |

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.

Posted by ovidiu at 04:57 PM |

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!

Posted by ovidiu at 04:10 PM |

November 19, 2002

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.

Posted by ovidiu at 06:57 AM |

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.

Posted by ovidiu at 02:24 AM |

September 27, 2002

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="">
     <map:part element="news" ns="" src="cocoon:/news/slashdot.xml"/>
     <map:part element="news" ns="" src="cocoon:/news/moreover.xml"/>
     <map:part element="news" ns="" src="cocoon:/news/xmlhack.xml"/>
    <map:transform src="stylesheets/news/news.xsl"/>

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):

   <title>A Simple Page using Content Aggregation</title>
      <cinclude:include src="cocoon:/news/slashdot.xml" element="slashdot" ns=""/>
      <cinclude:include src="cocoon:/news/moreover.xml" element="moreover" ns=""/>
      <cinclude:include src="cocoon:/news/xmlhack.xml" element="isyndicate" ns=""/>

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"/>

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.

Posted by ovidiu at 01:52 AM |

September 23, 2002

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.

Posted by ovidiu at 04:30 PM |

September 10, 2002

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.

Posted by ovidiu at 11:58 AM |

September 09, 2002

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.


With the control flow architecture in place a Cocoon Web application is split in three different conceptual layers, using the well-known Model-View-Controller (MVC) pattern:

  • Model: the business logic, e.g. Java classes which implements the meat of your application.
  • View: the collection of the XML pages and XSLT stylesheets that give a visual representation to your business objects. In Cocoon the pages used in the View layer can be simple XML files or XSP pages that use the JXPath logicsheet. More on this later.
  • Controller, which is coordinating the sequence of pages being sent to the client browser, based on the actions taken by the user. In Cocoon, the Controller is a specialized engine which uses a modified Rhino JavaScript implementation which supports continuations as first class objects. From a user (really a developer) perspective, the Controller is nothing else than a collection of JavaScript files running on the server side.

The general flow of actions in an application which uses the control flow is as described below.

The request is received by Cocoon and passed to the sitemap for processing. In the sitemap, you can do two things to pass the control to the Controller layer:

  • you can invoke a JavaScript top-level function to start processing a logically grouped sequences of pages. Each time a response page is being sent back to the client browser from this function, the processing of the JavaScript code stops at the point the page is sent back, and the HTTP request finishes. Through the magic of continuations, the execution state is saved in a continuation object. Each continuation is given a unique string id, which could be embedded in generated page, so that you can restart the saved computation later on.

    To invoke a top level JavaScript function in the Controller, you use the <map:call function="function-name"/> construction.

  • to restart the computation of a previously stopped function, you use the <map:continue with="..."/> construction. This restarts the computation saved in a continuation object identified by the string value of the with attribute. This value could be extracted in the sitemap from the requested URL, from a POST or GET parameter etc. When the computation stored in the continuation object is restarted, it appears as if nothing happened, all the local and global variables have exactly the same values as they had when the computation was stopped.

Once the JavaScript function in the control layer is restarted, you're effectively inside the Controller. Here you have access to the request parameters, and to the business logic objects. The controller script takes the appropriate actions to invoke the business logic, usually written in Java, creating objects, setting various values on them etc.

When the business logic is invoked, you're inside the Model. The business logic takes whatever actions are needed, accessing a database, making a SOAP request to a Web service etc. When this logic finishes, the program control goes back to the Controller.

Once here, the Controller has to decide which page needs to be sent back to the client browser. To do this, the script can invoke either the sendPage or the sendPageAndContinue functions. These functions take two parameters, the relative URL of the page to be sent back to the client, and a context object which can be accessed inside this page to extract various values and place them in the generated page.

The second argument to sendPage and sendPageAndContinue is a context object, which can be a simple dictionary with values that need to be displayed by the View. More generally any Java or JavaScript object can be passed here, as long as the necessary get methods for the important values are provided.

The page specified by the URL is processed by the sitemap, using the normal sitemap rules. The simplest case is an XSP generator followed by an XSLT transformation and a serializer. This page generation is part of the View layer. If an XSP page is processed, you can make use of JXPath elements to retrieve values from the context objects passed by the Controller.

The JXPath elements mirror similar XSLT constructions, except that instead of operating on an XML document, operate on a Java or JavaScript object. The JXPath logicsheet has constructs like jpath:if, jpath:choose, jpath:when, jpath:otherwise, jpath:value-of and jpath:for-each, which know how to operate on hierarchies of nested Java objects. Historically the namespace is called jpath instead of jxpath, we'll probably change it to the latter before the next major release.

A special instruction, jpath:continuation returns the id of the continuation that restarts the processing from the last point. It can actually retrieve ids of earlier continuations, which represent previous stopped points, but I'm not discussing about this here to keep things simple.

Going back to the sendPage and sendPageAndContinue functions, there is a big difference between them. The first function will send the response back to the client browser, and will stop the processing of the JavaScript script by saving it into a continuation object. The other function, sendPageAndContinue will send the response, but it will not stop the computation. This is useful for example when you need to exit a top-level JavaScript function invoked with <map:call function="..."/>.

The above explains how MVC could be really achieved in Cocoon with the control flow layer. Note that there is no direct communication between Model and View, everything is directed by the Controller by passing to View a context object constructed from Model data. In a perfect world, XSP should have only one logicsheet, the JXPath logicsheet. There should be no other things in an XSP page that put logic in the page (read View), instead of the Model. If you don't like XSP, and prefer to use JSP or Velocity, the JXPath logicsheet equivalents should be implemented.

Basic usage

As hinted in the previous section, an application using Cocoon's MVC approach is composed of three layers:

  • a JavaScript controller which implements the interaction with the client

  • the business logic model which implements your application

  • the XSP pages, which describe the content of the pages, and XSLT stylesheets which describe the look of the content.

In more complex applications, the flow of pages can be thought of smaller sequences of pages which are composed together. The natural analogy is to describe these sequences in separate JavaScript functions, which can then be called either from the sitemap, can call each other freely.

An example of such an application is the user login and preferences sample I've just checked in CVS:

This application is composed of four top-level JavaScript functions: login, registerUser, edit and logout.

The entry level point in the application can be any of these functions, but in order for a user to use the application, (s)he must login first. Once the user logs in, we want to maintain the Java User object which represents the user between top-level function invocations.

If the script does nothing, each invocation of a top-level function starts with fresh values for the global variables, no global state is preserved between top-level function invocations from the sitemap. In this sample for example, the login function assigns to the global variable user the Java User object representing the logged in user. The edit function trying to operate on this object would get a null value instead, because the value is not shared by default between these top-level function invocations.

To solve the problem, the login and registerUser functions have to call the cocoon.createSession() method, which creates a servlet session and saves the global scope containing the global variables' value in it. Next time the user invokes one of the four top-level functions, the values of the global variables is restored, making sharing very easy.

Even if you don't need complex control flow in your application, you may still choose to use the MVC pattern described above. You can have top-level JavaScript functions which obtain the request parameters, invoke the business logic and then call sendPageAndContinue to generate a response page and return from the computation. Since there's no continuation object being created by this function, and no global scope being saved, there's no memory resource being eaten. The approach provides a clean way of separating logic and content, and makes things easy to follow, since you have to look at a single script to understand what's going on.

Posted by ovidiu at 03:03 AM |

August 20, 2002


Cocoon | Java

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.

Posted by ovidiu at 11:57 AM |

August 17, 2002

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.

Posted by ovidiu at 11:34 AM |

August 07, 2002

Wish list for a Weblog tool

Cocoon | Weblogs

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.

Here is the list:

  • As with MT, and unlike Radio, the Weblog tool should reside on the Web site only. No installation on the user's desktop should be required, other than perhaps a simple Weblog editor which communicates over XML-RPC with the server. In my case, this editor would have to be XEmacs, of course. Other free software/open source tools are available as well.
  • The Weblog tool should have the notion of multiple users or authors, each managing one or more weblogs. It should allow multiple users to author the same weblog.
  • The system should have the notion of an administrator, which manages the permissions of users. The administrator should not be an user.
  • As with MT, the system should generate static HTML pages for the Weblog reader. Dynamically generating HTML pages would quickly become a problem when the system is deployed within limited resources available, such as those imposed by cheaper accounts at various ISPs. The management interface for the Weblog author would have to be dynamic though, to permit the management of the Weblog.
  • The system should provide two views of the generated Weblog. One view should be public, accessible to external viewers. The other view should be visible to the Weblog author only, and it will allow him/her to customize the look and feel of the site without afecting the public view. Once the author is happy with the look and feel of the private view, this could be published as the public view.

    With MT you get only one view, the public view. Each time you want to change something in the Weblog look, the changes become immediately visible to the public, which is not a good thing. Of course, you can setup a private area which uses the same data, but that's an administrative headache which could be avoided.

  • The system should have the ability to run periodic tasks on behalf of the user. This could be used to run blogroll scripts, calendar updates or any other action which causes the static HTML regeneration to happen.
  • It should be possible to edit Weblog entries in languages other than XHTML. I specifically have in mind the ability to edit entries using Docbook, xdocs or any other custom built XML format. This would give the ability to easily change the generated HTML markup or to generate entirely different markup, like plain text or XSL-FO for PDF generation.
  • The user should have the posibility of specifying custom XSLT stylesheets for different markup generation. The system should also allow arbitrary XML processing to happen on the original markup.
  • With the ability to edit Weblog entries in an XML format, a dictionary of abbreviations could be easily defined. This could be implemented either as XML entities or as XML elements which are translated to their definition by custom XSLT stylesheets.
  • The system should be written using components which plugin into the system easily. Ideally, it should be easy to write such components using any scripting language.
  • The system should have a clearly defined internal API, which exposes all the major items in it: entries, categories, stories, components etc. These internals should be exposed to all the scripting languages supported. Components written in different languages should be able to inter-communicate.
  • New components should be easily added to the system. However this task should be under the control of the administrator, which could install these components and make them available to users, perhaps in a selective, per-user maner, to permit a pay-per-use model.

In my opinion, Cocoon can solve most of these problems. One thing it badly misses is the ability to easily add new components to the system, and make them available in a selective manner, and the ability to have these components written in different scripting languages.

Posted by ovidiu at 10:20 PM |

July 31, 2002

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.

Cristopher Oliver came up a while ago (in an email dated May 20) with an idea of how to share the JavaScript bytecodes among various users, yet keep the variables space separate:

I looked into this briefly and I think the following approach might work: precompile scripts using Context.compileReader() to Script objects instead of using Context.evaluateReader(). The compiled Script object is immutable and can be shared between threads. You can then evaluate the script on 'thrScope' via Script.exec(context, thrScope).

This requires that all the script files that need to be read have to be aggregated as one single large file. I'm using a SequenceInputStream to do this, which works fine except for the fact that file location is lost. This means that error reporting is pretty much useless.

What I want to do is create a specialized class which is able to keep track of source files and their line numbers. The JavaScript error reporting will then be able to use this object to report the correct location.

Posted by ovidiu at 02:44 PM |

June 25, 2002

Java with continuations


Christopher Oliver points out, 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.

Posted by ovidiu at 11:23 AM |
Cool stuff
  Arduino TinyWebServer: part 3 and part 2
More from me
Picture gallery
Copyright © 2002-2016 Ovidiu Predescu.