Hash: SHA1

Seven months passed since the release of Radical 0.65, and it seems like
it's about time to make an additional public release:-) (Hopefully, releases
will be more often from now on)

The list of major changes and enhancements are listed below - there is even
more detailed change log in the tarball itself.


- From radical's homepage:

Or, alternatively, from Rubyforge:

= Version 0.7

This doent refers only to part of the changes in 0.7, please refer to
the full changelog(extracted from the subversion repository) for more detailed

* FastCGI support

In addition to it's own webserver, Radical can now use fcgi.rb in order to
process requests passed via a fastcgi connection, supporting both unix and
tcp sockets.

This can be combined with mod_fastcgi, or any other fastcgi enabled server,
in order to integrate easily into an existing setup.

As a result, the older Apache<=>DRb<=>Radical hack is considered deprected and
has been removed.

* Modularity, and lot's of it:-)

The monolithic, all-in-one approach was starting to show it's age, and I
needed a better way of maintaining all of the handlers and stuff - the
traditional categorical directory structure with require seemed to be

This is how plugin-engine was born. it's not actually a plugin-engine at
all, it's functionality is closer to that of primitive package manager.

Each component, be it the XmlRpc handler, the HTTP server, or even the
templating engine, is located in a seperate subdirectory, with a meta-data
file(actually it's a ruby script that runs in a special context), and init
script that loads the rest of the stuff.

Each "plug-in" has debian-inspired dependencies, either on other plugins, or
even "normal" ruby modules, using a simple trick.

In fact, radical.rb most important duty is to load the
plugin/module/extension/you-name-it radical-core

* Various speed improvments

See docsrc/benchmark.rdoc for updated benchmarks.

The C version of MTServer has been redesigned, and it's no longer works in the
same way as the Ruby version. This results in improved average response
time, and seems to reduce RAM footprint as well.

Several common code pathes were optimized further, although the improvment
is very marginal

The only remaining issue is that the C code is suspectable to the (GCC?) bug
described at ruby-talk:66239, but there isn't much I can do about it;-(

* YAML Configuration dropped, long-live XML:-)

Maintaining two configuration formats was proven to be "pain-in-the-a*s", at
that time YAML's API was still changing, and eventually I've found XML
better for my aims.

Also, due to other changes, such as modularization, the pd tree had to
be accessable from various places, having to deal with two API's was an

Eventually I have dropped the YAML configuration related code, so only XML
is accepted now.

In addition, there are bad news and good news about the XML configuration.
the bad news that it has changed once again - the good news is that the
syntax is now defined in a DTD, and it's unlikely to change(although
extensions are possible).

* RPortal system

RPortal is a modular portal system used in radical's website, it doesn't
provide much currently, mostly primitive software index, simple news
publishing+talkback, and a bug reporting system.

* Support for POST file attachments

Multipart parsing code has been borrowed from the mod_ruby project, enabling
support for multipart/form-data POST submissions

* XSS protection

All incoming GPC data is now sanitized and escaped by default using
CGI::escapeHTML, providing some degree of protection from XSS attacks(Cross
Site Scripting).

If a programmer considers an HTML input valid, then it must be unsanizied
(using #unsanitize! method).

* CGI handler

Radical can now call external programs and delegate incoming request using
the CGI protocol - work has been inspired
Version: GnuPG v1.2.2 (GNU/Linux)