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?
I am one of the people the requires web farms support. I do not think there are that many areas where the farm is treated differently. It really comes down to using central data stores instead of local ones. XML files for settings is great, but for farms a way to approach it is to store the settings in a central DB, then generate the XML files for each server as necessary. Some kind of dirty bit approach could tell Rainbow it needs to refresh the local file. As long as the settings and content both use a pluggable DAL then there should not be a problem, but even on the farms I like to optimize as much as possible. This will give speed to the product, but also allow for maitaining the central repositiory for everything. The other big issue has to do with caching. Caching on farms can be difficult when data is changing, but displaying data is not a problem once the cache is refreshed. I have seen some articles for refreshing the cache in a farm setup. Like the settings mentioned above, if the data is in a DB and then some kind of local XML file can be used to tell the cache that it needs to refresh then that might work great. .NET Caching supports an XML file depnedancy and can be configured to cause a refresh when the XML file is updated. I do not think it will be hard to come up with a data model that works optimally for farm and non-farm configurations. As one of the primary people concerned with farm support I will be happy to help on that aspect and work on a plan for supporting farms without complicating everyone elses life. I am thinking that a single server that uses XML files as the datastore could still use the techniques I have mentioned even though they might not be necessary, they would not hurt anyting. Another thought might be to make all of the caching and settings items work differently for central DB systems (SQL, mySQL, Oracle, Web Services, etc), meaning they would do the extra work for local caching and local settings. If a local DB (Access, XML, other File based) is used then this work would not be necessary. In other words, perhaps it becomes a function only of data store components that are not local file based.