We hope the next major release of Chicago Boss will be 1.0, targeted for Autumn 2011. This page is an informal description of the 1.0 goals.
Status: Everything implemented but .rel and .appup files.
As of 0.6 apps written with Chicago Boss are standalone OTP applications that simply list CB as a dependency. Still remaining are to produce proper .appup and .rel files for doing application upgrades and downgrades.
Status: Implemented as of 0.6
Status: Implemented as of 0.6
Status: Implemented as of 0.6
Status: Not done
A number of internal CB services (BossSession, BossCache, BossDB) use a single registered process and are a bottleneck under load. They need to be broken out to use worker pools, e.g. https://github.com/devinus/poolboy
- Query pre-fetching, see Issue #4
- CouchDB database adapter
Memcache session adapterImplemented in trunk, needs testingUpdate records via admin interfaceImplemented in 0.5.5Bulk import/export of data in the admin interfaceImplemented in 0.5.5
The following features may be implemented sooner than 2.0 or perhaps never. It’s just a collection of ideas for future directions for Chicago Boss.
ErlGuten is a nifty pure-Erlang project for laying out PDF documents. It needs some work, but combined with ErlyDTL it could be an easy way to generate PDF documents on the server similar to PrinceXML. Possible applications include printing tickets, receipts, transaction histories, bills, and many others.
What sells? A built-in framework for performing experiments would help people build websites that attract interest and retain users. The focus should be on presentation-level experiments: colors, images, headlines, and copy. CB would compute summary statistics and perform basic hypothesis tests, and make multivariate data available for off-line analysis. The syntax could be as simple as
<h1>{% test "Erlang web MVC + Comet" "Build something big." %}</h1>
The experiments should be closely tied to sessions in order to measure subsequent activity. It would be great to show statistics on all database activity without any configuration, e.g. updates to particular DB fields, creation and deletion of certain types of records, etc. (Of course, configuration would be needed to focus attention on key metrics.)
An admin interface that could generate diff files to close an experiment would be awesome.
Chicago Boss can be deployed in an Erlang cluster where every node knows about every other node. It would be great to provide a slick HTML5 operational dashboard that shows timelines of system statistics from each node (and possibly creates custom alerts). Using BossNews, statistics could also be generated for database activity (e.g. incoming orders). The goal would be to replace the existing monitoring stack: collectd, RRDtool, and Cacti.
At present, services provided by the master node (message queue, in-memory sessions) will go down if the master node fails. To fulfill the promise of high reliability, redundancy should be provided so that taking out any one node of a CB cluster will not cause any messages or sessions to be lost.
To overcome the perception that Erlang is “weird” the CB process should act as a regular UNIX daemon that handles UNIX signals. Patching the Erlang VM will be necessary, but hopefully Ericsson will like the idea. The CB signal interface should be similar to Nginx, e.g. SIGHUP reloads config, SIGUSR1 reopens log files, SIGUSR2 upgrades code, etc.