ACS 4 Subsites Requirements
by Rafael H. Schloming and Dennis GregorovicIntroductionThe following is a requirements document for ACS 4 Subsites, part of the
ACS 4 Kernel. The Subsites system allows one ACS server instance to serve
multiple user communities, by enabling the suite of available ACS
applications to be customized for defined user communities.Vision StatementMany online communities are also collections of discrete subcommunities,
reflecting real-world relationships. For example, a corporate
intranet/extranet website serves both units within the company (e.g.,
offices, departments, teams, projects) and external parties (e.g., customers,
partners, vendors). Subsites enable a single ACS instance to provide each
subcommunity with its own "virtual website," by assembling ACS
packages that together deliver a feature set tailored to the needs of the
subcommunity.System OverviewThe ACS subsite system allows a single ACS installation to serve multiple
communities. At an implementation level this is primarily accomplished by
having an application "scope" its content to a particular package
instance. The request
processor then figures out which package_id a particular URL references
and then provides this information through the ad_conn api ([ad_conn
package_id], [ad_conn package_url]).The other piece of the subsite system is a subsite package that provides
subsite admins a "control panel" for administering their subsite.
This is the same package used to provide all the community core functionality
available at the "main" site which is in fact simply another
subsite.Use-cases and User-scenariosThe Subsites functionality is intended for use by two different classes of
users:Package programmers (referred to as 'the programmer') must
develop subcommunity-aware applications.Site administrators (referred to as 'the administrator') use
subsites to provide tailored "virtual websites" to different
subcommunities.Joe Programmer is working on the bboard package and wants to make it
subsite-aware. Using [ad_conn package_id], Joe adds code that only displays
bboard messages associated with the current package instance. Joe is happy to
realize that ad_parameter is already smart enough to return configuration
parameters for the current package instance, and so he has to do no extra
work to tailor configuration parameters to the current subsite.Jane Admin maintains www.company.com. She learns of Joe's work and
would like to set up individual bboards for the Boston and Austin offices of
her company. The first thing she does is use the APM to install the new
bboard package.Next, Jane uses the Subsite UI to create subsites for the Boston and
Austin offices. Then Jane uses the Subsite UI to create bboards for each
office.Now, the Boston office employees have their own bboard at
http://www.company.com/offices/boston/bboard, and similarly for the Austin
office. At this point, the Boston and Austin office admins can customize the
configurations for each of their bboards, or they can just use the
defaults.Related LinksTest plan (Not available yet)Requirements: Programmer's APIA subsite API is required for programmers to ensure their packages are
subsite-aware. The following functions should be sufficient for this:10.10.0 Package creationThe system must provide an API call to create a package, and it must be
possible for the context (to which the package belongs) to be specified.10.20.0 Package deletionThe system must provide an API call to delete a package and all related
objects in the subsite's context.10.30.0 Object's package informationGiven an object ID, the system must provide an API call to determine the
package (ID) to which the object belongs.10.40.0 URL from packageGiven a package (ID), the system must provide an API call to return the
canonical URL for that package.10.50.0 Main subsite's package_idThe system must provide an API call to return a package ID corresponding
to the main subsite's package ID (the degenerate subsite).Requirements: The User InterfaceThe Programmer's User InterfaceThere is no programmer's UI, other than the API described above.The Administrator's User InterfaceThe UI for administrators is a set of HTML pages that are used to drive
the underlying API for package instance management (i.e. adding, removing, or
altering packages). It is restricted to administrators of the current subsite
such that administrators can only manage their own subsites. Of course,
Site-Wide Administrators can manage all subsites.20.10.0 Package creation20.10.1 The administrator should be able to create a
package and make it available at a URL underneath the subsite.20.20.0 Package deactivation20.20.1 The administrator should be able to deactivate
any package, causing it to be inaccessible to users.20.20.5 Deactivating a package makes the package no
longer accessible, but it does not remove data created within the context of
that package.Revision HistoryDocument Revision #Action Taken, NotesWhen?By Whom?0.1Creation08/18/2000Dennis Gregorovic0.2Edited, reviewed08/29/2000Kai Wu