ReDBox 2.0 Roadmap and planning

Owned by Andrew Brazzatti
Last updated: 25 Oct, 2016

ReDBox 2.0 Plans

  1. Separate presentation application from backend via RESTFUL API - By separating the presentation application from the backend we can better manage the technologies for the two components, have greater flexibility in how the major components are deployed and also open the backend up for greater integration with other applications.
  2. Migrate to single web application framework - Current application is an mix of programing languages, superseded frameworks and custom developed libraries (Java, python, jython, Tapestry, Velocity Templates). Objective is to rewrite web portal to a more commonly used community supported framework making it easier to maintain. This will also provide an opportunity to modernise the look and feel of the user interface, using best practice UX design and modern interface elements.
  3. Improved theming in web portal - Provide increasing options for theming of web portal including changes to make it modern and responsive to mobile devices.
  4. Provide a user interface to configure forms - Currently in ReDBox the forms are generated based on JSON configuration which require some level of technical proficiency to change. Providing a user interface to configure the forms (similar to a CMS) will allow non-technical administrators to configure them as desired.
  5. Update backend codebase - As with the presentation layer, the backend uses a number of superseded frameworks and custom developed libraries. This includes revising the metadata storage component, currently a custom developed no-sql solution using the file system to store data. It currently has limited tooling support for general operational maintenance (e.g. backups and recovery), high support requirements and potential performance issues when the number of records gets sufficiently large.
  6. Allow for synchronous processing - A key feature of ReDBox is its ability transform any data in the system into a number of different renditions (e.g. using the metadata to produce a PDF report). In ReDBox 1.x all processing of the metadata is asynchronous which is good for some use cases where the transformation takes a long time but requires provisions in the user interface so that the user understands what is taking place (e.g why the rendition isn't available immediately). The ability to allow configurable synchronous processing (on the same thread) in the same way as we do for asynchronous processes will resolve this.
  7. Implement new Harvester using APIs - ReDBox and Mint contain simple harvesters to ingest records from CSV files on the file system. Some work has been done in the ReDBox 1.x stream to harvest data from other sources (such as HTTP or by pulling data from a JDBC/ODBC data source) but these techniques can be further refined and formalised within the platform using the RB 2 APIs.

ReDBox 2.0 High Level Architecture

ReDBox 2.0 Server Components