zumbrunn.com - Server-Side Javascript Standard Library

Server-Side Javascript Standard Library

Kevin Dangoor asks what Server Side JavaScript needs and launches more talk about a standard library for Javascript on the server-side.

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.

For Helma NG , the way modules are included is changed to eliminate any possible namespace conflicts. Each module in Helma NG lives in its own scope and can selectively import other modules or portions thereof into its scope. Here again, when modules are imported in different scopes, each module is only actually loaded once.

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.

29.1.2009, 19:58

Is the Bespin web-based code editor the ideal future ServerJS IDE?

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.

13.2.2009, 14:50

New Eclipse Helma plugin project

The helma4eclipse project provides a set of plugins for Eclipse, building a perspective for Helma 1.x based web app development. The features implemented so far by Franz Philipp Moser include a preferences pane, the ability to start/stop Helma from Eclipse, logging to the Eclipse console (you need to set "logdir = console" in server.properties) and the ability to browse the running apps, including their prototypes and skins, in a live outline. You can grab that very first version here .

1.3.2009, 10:08

The best solution is that one isn't needed

Nuff said.

20.3.2009, 19:34

ReverseHttp and RelayHttp

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

24.3.2009, 10:07

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.

8.4.2009, 23:31