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