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 Giapeto, 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 isntances of these resources.

Details

Things to consider:

• url mappings
  • permissions
  • discoverability
  • interaction with multi-domain setups.
    • is a space a domain?
    • or are they seperate 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 occassion, 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, er, on paper, er, WikiThinking? or something, 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 giapeto content for public site, 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 and Wiki:DeleteWhenCooked. --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