chrisco edited this page Oct 25, 2012 · 3 revisions

The Road to 1.0

We hope the next major release of Chicago Boss will be 1.0, targeted for Autumn 2011 (what is the new target date?). This page is an informal description of the 1.0 goals.

Goal 1: Full OTP compliance

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.

Goal 2: News API (data model event notifications)

Status: Implemented as of 0.6

Goal 3: Distributed setups

Status: Implemented as of 0.6

Goal 4: Cache system

Status: Implemented as of 0.6

Goal 5: Performance/scalability testing

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.

Minor Features for CB 1.0

  • Query pre-fetching, see Issue #4
  • CouchDB database adapter
  • Memcache session adapter Implemented in trunk, needs testing
  • Update records via admin interface Implemented in 0.5.5
  • Bulk import/export of data in the admin interface Implemented in 0.5.5

Chicago Boss 2.0

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.

PDF generation

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.

Web experiments

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.

Operational dashboard

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.

Fault tolerance

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.

UNIX signal handling

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.