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…
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.
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
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.
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.
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?
-----Original Message----- From:
On Behalf Of Geert Audenaert Sent:28 March 2003 To:
firstname.lastname@example.org Subject: [Rainbowportal-devel]
multi-database setup proposal
created a little program in which I’ve put some example code of how we
could modify Rainbow to support multiple databases.
you have some time, plz take a look at it and me your thought’s.
Audenaert Syntegra, creating
winners in the digital economy +32 2 247 92 20 - check us out
at www.syntegra.be *******************