Horde Spaces

Proposal for implementing a Horde-wide method of handling multiple instances of site-like resources.

Problem

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.

Details

Things to consider:

• url mappings
• permissions
• discoverability
• interaction with multi-domain setups.
  • is a space a domain?
  • or are they separate things?
  • are users contained in a space, or do users span multiple spaces? (seems more useful for a user to be able to access multiple spaces)

--Chuck

I couple thoughts:

• We have one client that essentially needed a different set of templates for each domain, but they needed to otherwise work (largely) the same. Giapeto needed different content.
• On more than one occasion, we've had people request that we hack per-domain address books. With LDAP, we can plug in the domain as a key, with SQL, we fudge the table name or patch the driver to exclude based on auth domain.

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