CouchDB

I've been trying to figure out how to make MySQL or SQLite play nice with DCI, and there always seems to be some compromise when I design the interaction. In response to this, the default data storage method for Wax (besides SQLite) will be Apache's CouchDB.

CouchDB is a project started out of the need for a document-based database rather than a relational database. The bulk of web applications don't ever use most of the power of a relational database like MySQL or PostgreSQL, so why not use a data-storage solution that is more scalable outside of the application itself?

CouchDB uses HTTP to store/fetch data, using the 4 major HTTP request types: GET PUT POST and DELETE. The entire database is directly queried through HTTP, meaning that data can be requested directly from PHP or JavaScript, allowing for a more fluid interaction between the client and the data itself, and less need for requests back to the webserver.


CouchDB binaries are available for Mac OS X and Windows XP/Vista, and most package management systems for Linux have a CouchDB package.

DCI with REST APIs

DCI's extremely flexible runtime structure opens up several possibilities for RESTful routing. Since DCI uses a role-based runtime structure, we can use URLs to query the application as a dynamic source of data instead of a series of static links that provide access to the underlying system. This method allows for nearly transparent controllers, as explained below:

MVC REST Routing -- Standard Convention

Most MVC based frameworks, including Rails and Symfony, use a controller-centered routing model. For example, the default routes in rails translate to:

http://site.com/app/controller/
http://site.com/app/controller/action
http://site.com/app/controller/action/id

This routing method works for most web based applications but with DCI, there is no static routing to a controller, but rather a 'request for a dynamic context execution'.

DCI REST Routing -- Proposed Method

With DCI routing, there is a special consideration to take into account when designing a system. Since the runtime network is dynamically created, the same base actions can take place from completely different places with different actions.

For example, if we were creating a message board application, we could create a post from either a logged in context or an anonymous (application) context. The access URL would be different, but the same base action would be taking place with different 'arguments':

http://site.com/app/{context}/{data model}/{action}/{args}
http://site.com/app/app/post/create
http://site.com/app/user/username/post/create

In this situation, there are 2 distinctly different contexts executing the same action (create) on the same model (post). The app context is the public application context that is used to anonymously perform system actions. These actions could be reading an about page, submitting a form on the contact page, or they could be posting anonymously on a message board. The user/username context is used to perform system actions as a specific individual. This allows for models and views to be created, then simply deciding which contexts can perform which actions. In this way, we can mostly replace the job of the controller (providing model data to the views) with simple REST routing.


The source code is currently being reworked to reflect these capabilities.