6.0.0-git
2024-04-24

Diff for Project/HordeSpaces between 3 and 4

+ 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 DeleteWhenCooked.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