describes a dynamic, ReST-style means of enrolment and participation in an HTTP network. The message/http and application/http MIME types defined by RFC 2616 are used to build a dynamically-configurable "Remote CGI" service.
Joining the World Wide Web as an HTTP server has been an ad-hoc, manual process. By using the protocol defined here, programs can provide services to the Web just as easily as they request services from the Web."
The defined protocol is similar to the widely used HTTP proxying protocol, but differs in that the proxied traffic is carried over an ordinary HTTP connection; the special syntax used by an HTTP proxy is avoided here."
is currently running on a python based backend, but I can see this project as a likely candidate for a backend implemented using the future standard library that the
Having a unified API for libraries in different environments would in
my opinion be nice especially because it would allow higher level
environments. One problem that has slowed this from happening in the
past has been that in Java-based environments like
makes the direct scripting of Java packages so easy, that
some stakeholders don't believe the added burden of maintaining an
would get from it.
projects in the realm of the Helma project and to other efforts for a
standard library for JS:
The current Helma 1 versions come with two libraries containing
several modules. The
provides modules for core functionality
such as Database, File, Ftp, Http, Smtp and SSH, some that extend
built-in prototypes, and a few others. The
modules such as DNS, MP3 and XML-RPC and utility modules such as i18n,
image manipulation, captcha, HtmlDocument, RemoteContent, Podcast, Rss
and other XML related modules.
Modules are included either via a configuration file or at runtime via
a method call. A module is only loaded once, even if included multiple
times. In the context of Helma 1, modules are loaded into the global
scope and they need to be nice and restrict themselves to a save
There has been
with the goal of a unified library/
modules architecture between different projects over in the Helma NG
group. One of the major goals in Peter Michaux's
is to provide a standard library and a shared module loading mechanism.
Hannes took a few days time to bring mod_gcj and rhinola up to date and prepared
new releases for both projects
mod_gcj now implements a pretty useful subset of the servlet specification.
Rhinola no longer depends on mod_gcj and can be deployed on any servlet container.
Have a look at the release notes for details.
mod_gcj is an Apache module to run Java code as closely embedded into
the HTTP server as possible using the
GCC/GCJ Java runtime and libraries.
GCJ treats Java as just another language
and compiles it down to native code. This makes it much lighter than most
traditional Java virtual machines, especially regarding memory footprint
and startup time.
Rhinola is a servlet based web scripting environment using the
. It was
originally conceived as showcase and playground for the mod_gcj Apache
module, but it should work with any
are looking for something conceptually similar but more complete,
a look at Helma NG.
Helma is 1.6.3 and
ready to be downloaded
! With over 10 years of development history, she is now more mature and more stable than ever. The latest list of refinements is a testament to that. The release isn't as minor as it sounds. Helma is just very conservative about her version numbers. This is really more like a 6.3 release than a 1.6.3. She is ready for your projects! For those of you that haven't already, it is now time to
Your email address:
The "Decentralize" Newsletter
Exchanging ideas for building a
decentralized fabric of society.
Making true democracy work on a larger
scale while decentralizing "everything",
benefiting from local diversity and
global synergies at the same time.