Following an online chat with Geert about this, I’m posting below a list of questions/points raised during that discussion (plus some new ones) so that others may comment…


  1. Geert confirmed that this scheme is “in line with” the 15seconds article that got me fired up about a pluggable data layer for Rainbow. The article is here.
  2. I believe strongly in the need to separate “settings data” from “module content data”. I’d agree that a Rainbow installation should use a single data store for all “settings data”, but I believe that each module should be able to nominate its preferred data storage technique. This would extend to modules within the same Rainbow instance being able to use a different data store than Rainbow is using for its settings data  – it might make use of the “supplied” data storage facilities or , if necessary, supply replacement or additional routines to achieve its own aims.
  3. I’m very keen to see XML included as one of the base choices for data storage and, further, that the FS is included as a storage location. “Database + SQL command” should be interchangeable with “XML source + XPath expression”. Indeed, XML is the primary candidate in my mind as the “data store of choice” for v2 Settings – the hierarchy of tabs (which introduces all sorts of complexities in SQL with self-related tables) is (by comparison) trivial in XML.
  4. Rainbow should provide, irrespective of the data source, a generic caching facility so that data requests are answered from cache whenever possible. Modules would provide “settings” to control “all instances” and “this instance” parameters for caching.
  5. The desire to maintain “web farm” capability in Rainbow complicates the issue further L: we should make a decision early in the game as to how this will be supported. It is always possible that we produce two versions of Rainbow – single server and multi-server – as a way of avoiding unnecessary complexity for the majority of Rainbow installations (which one presumes will be of the single server type). I could be wrong (please tell me), but I think this would only require two versions of the “Data Access Layer” – everything else would be common?


Happy programming!




-----Original Message-----
From: [] On Behalf Of Geert Audenaert
28 March 2003 13:40
Subject: [Rainbowportal-devel] multi-database setup proposal


Hi guys,


I’ve created a little program in which I’ve put some example code of how we could modify Rainbow to support multiple databases.


If you have some time, plz take a look at it and me your thought’s.






Geert Audenaert
Syntegra, creating winners in the digital economy
+32 2 247 92 20 - check us out at