Helma Logo
main list history
previous version  overview  next version

Version 8 by hannes on 03. December 2009, 16:29

For a task-oriented view of the Helma NG roadmap see the [github issue tracker](http://github.com/hns/helma-ng/issues).

The next Helma NG release is [0.4][Helma NG 0.4]. No release date has been set so far. We should probably look for a release in q4 2009.

Some tentative goals for the 0.4 release:

* Support for more future ServerJS APIs and modules such as system, file, binary.
* Make Narwhal run on Helma NG (again)
* JSDoc generated API documentation for modules and apps
* Ability to run Helma NG as service on Debian/Ubuntu
* Ability to run untrusted code in Helma NG
* Impvored documentation and tutorials

### Areas of work

* Filesystem:
    * duality of (commonjs) `file` and `helma/file`. Consolidate `file`, eventually bring over useful extra stuff from `helma/file`.
    * commonjs `file` module is incomplete and not up-to-date
    * jruby libraries for POSIX support need more work, documentation, sort out license issues etc
* HTTP client:
    * Transition to commonjs `io`, `binary` support instead of java APIs
    * Maybe switch to Jetty HTTP Client, enabling support for asynchronous requests
    * Related issues: <http://github.com/hns/helma-ng/issues/#issue/27>, <http://github.com/hns/helma-ng/issues/#issue/29>
* String extensions:
    * Maybe move all validation functionality (`isEmail`, etc) out of String.prototype into a separate validation module
* Command line tools: In addition to the generic bin/helma command, more special purpose commands/scripts might be useful:
    * `helma-web` - run a helma web application
    * `helma-admin` - run a helma admin script
    * `helma-doc` - run the helma jsdoc processor
    * more?
* Webapp
    * "continuation" support (`helma/webapp/continuation`): This was originally meant to use acutal JS continuations, then was watered down into a sort multi-page session framework. Do we really need this?
    * session support: currently, it's based on servlet session API. Do we need/want a pure commonjs implementation?