Index: openacs-4/packages/acs-core-docs/www/subsites-design.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/subsites-design.html,v diff -u -r1.26 -r1.27 --- openacs-4/packages/acs-core-docs/www/subsites-design.html 16 Feb 2005 00:21:03 -0000 1.26 +++ openacs-4/packages/acs-core-docs/www/subsites-design.html 4 Jun 2006 00:45:25 -0000 1.27 @@ -1,4 +1,5 @@ -Subsites Design Document

Subsites Design Document

By Rafael H. Schloming

+ +Subsites Design Document

Subsites Design Document

By Rafael H. Schloming

OpenACS docs are written by the named authors, and may be edited by OpenACS documentation staff.

*Note* This document has not gone through the any of the @@ -18,13 +19,13 @@ is, in fact, a discussion of how core OpenACS 4 components implicitly support subsites as a whole.

Historical Considerations

The subsites problem actually has several quite diverse origins. It was originally recognized as a toolkit feature in the form of -"scoping". The basic concept behind scoping was to allow one scoped +"scoping". The basic concept behind scoping was to allow one scoped OpenACS installation to behave as multiple unscoped OpenACS installations so that one OpenACS install could serve multiple communities. Each piece of application data -was tagged with a "scope" consisting of the (user_id, group_id, +was tagged with a "scope" consisting of the (user_id, group_id, scope) triple. In practice the highly denormalized data models that this method uses produced large amounts of very redundant code and in general made -it an extremely cumbersome process to "scopify" a module.

Before the advent of scoping there were several cases of client projects +it an extremely cumbersome process to "scopify" a module.

Before the advent of scoping there were several cases of client projects implementing their own version of scoping in special cases. One example being the wineaccess multi-retailer ecommerce. (Remember the other examples and get details. Archnet?, iluvcamp?)

The requirements of all these different projects vary greatly, but the one @@ -201,10 +202,10 @@ required for subsites. It is likely that as developers begin to use the subsites system for more sophisticated projects, it will become necessary to develop tools to help build tightly integrated packages. The general area -this falls under is "inter-package communication". An actual +this falls under is "inter-package communication". An actual implementation of this could be anything from clever use of configuration parameters to lots of package level introspection. Another area that is -currently underdeveloped is the ability to "tar up" and distribute +currently underdeveloped is the ability to "tar up" and distribute a particular configuration of site nodes/packages. As we build more fundamental applications that can be applied in more general areas, this feature will become more and more in demand since more problems will be