Geert Bevin on The Philosophy Behind RIFE

Posted by Scott Delap on Aug 17, 2006

Sections

Development

Topics

Java ,

Web Frameworks

Tags

RIFE

A few weeks back InfoQ covered the 1.5 release of the RIFE Java web framework. This week Artima Developer featured an extensive interview with RIFE founder Geert Bevin. In the interview Geert explains the history of RIFE. The questions then move on to how declarations help the framework:

A very simple example is your page URLs. One of the main problems in coding Web applications is how to put a URL into a form or a link: How do you insert that URL there so that if you reuse that application, the URL remains consistent? For us, that was very important because we work on multi-language sites, and we have customers who ask for specific localized URLs. We have to be able to change a URL into a French URL, but keep the same functionality. For that to work, you should be able to specify a URL in one place, and the framework should ensure the consistency of that URL in the view. RIFE allows you to do that...

They also talk about new features in 1.5:

...That's also an example that declarations don't have to be specified in an XML file. A lot of people today are allergic to XML. Every declaration and configuration in RIFE can be specified in plain Java. It's not just a matter of setters and getters, leaving you with having to invoke many calls on the same object instance. Instead, we actually wrote out fluent interfaces that allow you to chain those calls. It looks very similar to a nested structure you would have in XML, except that it's in Java...

Towards the end of the interview Geert provides a good example of using continuations in RIFE:

People have also been using continuations for event-based systems. Suppose you have an events flow declaration that takes several steps chained together. When a certain event happens, an application has to perform an action.

What you'd typically do is poll for state: You would have some kind of sleep time, and then poll to see what the state is, and if the state is not what you want, you just wait a little while, and when the required state is detected, you take the correct step.

Continuations turn that problem around. If you're at a step that requires additional information to continue, you can capture a continuation and stop the execution completely. That continuation becomes a dead object—it doesn't do anything any more. That dead object is then stored, and somewhere in an event handler you register events as being related to that object. When an event occurs, you look up all the continuations that relate to that event, and then start those continuations up again. Instead of polling, you have a very low-overhead system. We've had reports from people that the performance of their applications improved dramatically this way.

1. Back to top

   continuations on the JVM

   by Joost de Vries

   I think it would be great if the JVM provided support for storing a frame at the moment of blocking on IO and reloading it when an event comes in consistent with the unblocking. This would make it possible to use continuations in plain very readable java, or other languages on the VM.
   In other words: given the vision of the JVM and existing bytecode programs as a platform for multi-language development I think Sun would be wise to build JVM-level support for selected language features. I think that only supporting scripting is a too limited view of the future of programming languages. Support for continuations is one JVM feature one could wish for. Other features could be multi-method support, ...
   Yes, I'll say it out loud; I'm a Java idealist.

   Reply

• Older >