It took a while, but finally I converted all content from the old rifers.org wiki to Confluence, thanks to a free license that has been generously offered by Atlassian. This was also the perfect occasion to update RIFE's cookbook with all recent information that has been written about RIFE development. Have fun!

Tonight someone called me at 02h30 on my cell phone and left a voice mail. I just listened it and was quite baffled. A women's voice says that it's disgusting that I'm sending viruses to people and threatens to come over to kick my arse if I continue.

Clearly some virus spoofed its 'from' address or some other trick to make it appear as if it came from one of my own email addresses. That women then set out to find who I was and to threaten me.

Even though I don't run any windows operating system, take all possible virus countermeasures (since they clutter my inbox), filter them out at the mailserver etc etc etc, I could still be harmed by it ... but not on the computer. Imagine what will happen if this plague continues and people continue to misinterprete what they see. If you can get aggressed because you offended someone with a few words on the street ... I would not be surprised if people were tracked down and beaten up if someone's computer has been wiped and infected again for the 100rd time.

It's a sad world :-(

I've been thinking for a while about how to describe RIFE's template engine to people that are used to 99% of the ones that are out there (JSP, PHP, Velocity, Webmacro, Tea, ...). Almost all template engines start out with a desire to seperate design from logic, they allow users to push or pull values into the template and then they get stuck. Design is far more complex than setting a couple of values, so they start providing simple logical constructs and loops, maybe even variables, blocks and scopes, functions to reuse code, etc etc ... and in the end run incorporate an entire language (JSP) or create a new one (PHP). All this is based on the assumption that the logic provides data to the design which is then decorated and rendered from within the template. Imho, a fundamental last step is missing which creates an overly complex model to try to simulate it.

When data has been integrated into a design, a template engine should allow the logic to retrieve the result and use the concrete version of the templated layout for real output and manipulation. This means that together with incorporating data, a template engine should also provide results and thus be able to work in a bidirectional fashion instead of the limited common unidirectional approach.

All of a sudden the template engine then becomes extremely simple, no need to integrate any kind of logical constructs or loops, the same logic that provided the data is able to select or repeat results easily. It can extract and combine them and if the template engine is powerful enough, use it as a scratchpad to assemble all the pieces of the layout in an efficient manner. All the required information is already available in the logic. You also don't have to worry anymore about just how much logic bleeds into a template. The entire template becomes totally language independent and designer-friendly.

So, that is the fundamental benefit of RIFE's template engine (highlighted source) . Glad I was finally able to put this into words ;-)

Initially, RIFE templates were first converted to real Java source files and then compiled on-the-fly with a regular Java compiler. Since I started using ASM for the Java continuations engine of the web framework, I quickly throught that it would be a good idea to use it for generating bytecode directly from the template engine.

Since yesterday I got rather fed up with the wait everytime I modified a template file, I decided that I'd give it a shot. In less than half a day I got all the old code disabled and replaced by suitable ASM visitors. It truly is a great bytecode generation and manipulation library. A nice side effect is that if you don't precompile the templates for distribution (ie. only let them be generated at runtime) no disc access is performed at all. The bytecode is generated in memory and passed directly as a byte array to a dedicated classloader.

The speed benefits that I hoped this would offer definately made the effort worth-while. The pre-compilation of all templates of our latest project now takes 44 seconds instead of 8 minutes 33 seconds, that's almost 12 times faster!!!