ES5 Candidate Specification

The fifth edition of ECMA-262, the
industrial standard scripting language specification
, which should later become the fifth edition of ISO-16262, has now reached the "Final Draft" state and will enter the testing and validation phase, on target for approval later this years.

In case you missed it, ES5 is the effort formerly known as ES3.1, and got renamed to ES5 in order to clean up the confusion with the version numbers of the different proposals, skipping the ES4 version. "ES Harmony" would therefore one day be called ES6, not ES4.

"
This document
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."

"
This document
describes a protocol for tunnelling HTTP traffic over HTTP, with the goal of providing portable, general, securable access to the World Wide Web for programs running in restricted environments, including Javascript programs running in browsers.

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."

Bespin
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
ServerJS group
is attempting to build. Bespin together with Firebug and an integrated remote Rhino-Debugger seems capable of turning the web browser into the perfect Client-/Server-JavaScript IDE.

Having a unified API for libraries in different environments would in
my opinion be nice especially because it would allow higher level
modules to be shared between different server-side javascript
environments. One problem that has slowed this from happening in the
past has been that in Java-based environments like
Helma
,
Sling
and
Xjs
,
Rhino
makes the direct scripting of Java packages so easy, that
some stakeholders don't believe the added burden of maintaining an
additional API layer in javascript is reasonable for the benefit they
would get from it.

Some pointers to current server-side javascript library
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
HelmaLib
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
Jala library
adds further
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
namespace.

There has been
some discussion
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
xjs project
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
Mozilla
Rhino JavaScript implementation
. It was
originally conceived as showcase and playground for the mod_gcj Apache
module, but it should work with any
servlet container.
Rhinola is not a full featured server side JavaScript Runtime. If you
are looking for something conceptually similar but more complete,
have
a look at Helma NG.

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.
http://tinyletter.com/zumbrunn