Proposal for implementing a Horde-wide method of handling multiple instances of site-like resources.
Right now many Horde apps, such as Merk and Wicked, manage a single site-like resource (a wiki, a website, a store). It is less than ideal that a single Horde installation can't support multiple instances of these resources.
Things to consider:
--Chuck
I couple thoughts:
I'm thinking out loud, but there are two disjoint concepts here, it seems. First, what constitutes a "use domain" (which could be multiple DNS domains--we frequently have people register different spellings or abbreviations of their business name), or perhaps one class of user at one domain, e.g. "content managers" versus "public" versus "administrators"), and second what constitutes an "application set" -- and here we're thinking about several application instances. For example, internal and external wikis, or file manager for FTP site.
Hmm. I like this, because then we remove multiple address book support from Turba (we use multiple Turbas) and multiple VFS support from Gollem, etc.
Okay. This has been an attempt at thinking. Take whatever is useful.
--Jason
Question: Why would we remove multiple address book support from Turba?
--Mike Rubinsky
Hmm. It occurs to me now that I could be missing something, but my thinking went along these lines: If we now have an easy way to drop in multiple copies of Turba (each pointing at a different address book), this will do the same thing for users that having Turba support multiple address books does. In the interest of Wiki:DoTheSimplestThingThatCouldPossiblyWork, we remove the one option to reduce complexity and the effort required to maintain the code.
I'm curious why you are asking--are you seeing something that wouldn't work that way? Or thinking about the effort to remove the feature? Or something else?
--Jason
Unless I'm misunderstanding what you mean by `drop in multiple copies of Turba (each pointing at a different address book)` - the first thing that comes to mind is that we would lose most of the advantages that using Horde_Share in Turba gives us - setting up an arbitrary number of address books, with configurable permissions, the ability of users to create any number of additional address books on the fly etc... We can currently create any number of new 'public' address books - on the fly - without adding any additional tables to the database (if using a SQL source of course). I'm also wondering how this would work with contact lists/groups that contain contacts from multiple address books, would this be able to span across multiple instances of turba? Then, there's the question of how this would all tie into the api - how would we determine which instance would be the target for an api call, from say IMP?
--Mike