Is the Bespin web-based code editor the ideal future ServerJS IDE?
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
Release Candidate 3 contains some additional important changes, such as the totalUploadLimit value now being applied also to ordinary form post requests, as well as preventing a potential problem with the insertion order and making it easier to run Helma in other servlet containers.
Helma 1.6.3rc1 release candidate
contains numerous bug fixes and many minor improvements, such as support for secure HttpOnly session cookies, logging improvements, several changes to the way file paths to different resources are resolved, and Helma is now again backwards compatible with Java 1.4, to mention just a few.
Relative repository paths now resolve relative to Helma home directory, fixing bug 639.
Introduced hopdir servlet parameter to be able to set the helma directory.
The location of db.properties is now customizable using the dbPropFile server property, fixing bug 640
Fixed bug with closed database connections in very long running requests by making sure connections are re-checked every 10 seconds.
Changed HopObject.getOrderedView() to return a transient HopObject instead of a ListViewWrapper.
Fixed bug in request handling when incoming requests are attached to an existing response and the response is generated by directly accessing the res.servletResponse HttpServletResponse instance.
Go back to Java 1.4 compatibility. The few generics uses aren't worth it to require Java 1.5.
Made sub-properties updateable.
Logging improvements, such as an additional log message when a request starts evaluating, making commit log messages look nicer and easier to parse, and improved thread naming including thread ids in helma log messages.
Unified macro error handling, no longer dumping stack traces for macro errors.
Ampersand is no longer encoded as entity when encountered in macro tags.
Added support for secure and HttpOnly session cookies, with HttpOnly being enabled by default. The features are controlled through the httpOnlySessionCookie and secureSessionCookie app properties. We now compose and set the session cookie ourselves as this is the only reliable way to do it in a cross-servlet-container compatible way and without adding dependencies to the servlet container.
Fixed a problem with the code evaluation order of repositories added via app.addRepository().
Fixed app.xmlrpcCount to be increased for "new style" XML-RPC requests served by Jetty, fixing bug 629.
Changed code to not track unset() on non-persitable properties, fixing bug 633.
Fixed serialization for transient HopObjects.
Synchronize more methods in TypeManager as well as app.addRepository() to avoid memory race conditions.
Use LinkedHashMap for dirty node tracking to preserve insertion order.
Made checkXmlRpc work with content-types containing a charset subheader, fixing bug 628.
Continue parsing macro tags even if it is a comment. This is the only way we can correctly catch embedded macros. Fixes bug 588.
Only resolve direct prototype matches in parent chain, fixing bug 617.
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.