Makumba Whitepaper

The basic idea of Makumba application development is as follows:

• the Organisation describes the data in a simple and neutral Data Definition language
• a database layer reads the Data Definition and automatically generates code that represents and processes the data in a database engine. Several SQL engines are supported for now. Data is fully portable between different Makumba supported databases. Soon, data will be represented in XML
• a presentation layer reads the Data Definition and automatically generates a user interface. HTML interface is generated for now, through a JSP taglib
• the webmaster can adjust the default HTML presentation to the lowest detail
• OQL can be used to interrogate the database. The database layer uses the data definition to translate the OQL into the host SQL and provides the data in the format required by the data definition.
• the programmer can add "organisational logic" between the interface and the database depending on the organisation's needs

The following are high priorities of Makumba:

• phased development (easy to start an application in order to collect data, and to adjust it later on when further processing is needed)
• simplicity (a minimum necessary number of features, small code, easy to maintain)
• distributed development (people developing at different locations at different times)
• collaboration between programmers and webmasters, allowing them to put their skill and inclination to full use and not do jobs that are too boring or too difficult for them
• ability to finely adjust HTML interface
• platform and database engine independence
• data compatibility (for copying and replication) across multiple databases

• speed (most current database drivers are the minimum necessary, but they can be optimized using stored procedures and engine-specific features)
• multiple features for complex needs

• they are commercial (CFML, LDML)
• they don't put data definitions to full use in order to generate default interfaces during rapid application development
• their SQL queries are SQL engine dependent, making applications not portable across SQL engines

• they need a simple technology to base all the applications on. BEST had several legacy applications built with different technologies (Java, Lotus Notes), with different data formats, that needed to communicate better
• distributed development: BEST developers are not co-located, and meet rarely
• multiple platforms and database engines: a typical developer would use Windows and ODBC or MySQL databases. The developed software runs on Unix (Solaris or Linux) with Postgresql
• multiple member inclinations: programmers don't like to do web pages, so the simple interface that they generate with Makumba can later be adjusted by people who like to write web content
• need for small number of features that can be learned by members in a short time. BEST students only stay 3 years on the average in the organisation
• applications need to be started up fast and adjusted later on, when specialised people are available for programming work. In the meantime, data can be gathered.
• they already had experience with websites generated by Java servers: Java CGIs, servlets, JML (a technology they invented in 1996, similar to nowadays JSP, etc
• they found Lotus Notes programming much too heavy, with lots of unneeded features, hard to learn and its visual programming model was unsuited for distributed development.
• the Notes databases didn't intercommunicate sufficiently due to the specialisation need to achieve such communication
• Lotus Notes web content adjustment possibilities were low comparing to the HTML-oriented solutions like JML and JSP