[cvs] [Wiki] changed: HordeSpaces

[Chuck Hagenbuch]

chuck  Thu, 03 Apr 2008 14:52:43 -0400

Modified page: http://wiki.horde.org/HordeSpaces
New Revision:  1.5
Change log:  spelling, a few updates, etc.

@@ -3,9 +3,9 @@
 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.
+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:
@@ -14,9 +14,9 @@
 * permissions
 * discoverability
 * interaction with multi-domain setups.
  * is a space a domain?
- * or are they seperate things?
+ * 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
@@ -25,25 +25,24 @@

 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.
+* 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, 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.
+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.
+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
+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
+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