dotLRN Architecture

dotLRN is built on OpenACS 4.x, a modular architecture for community-oriented web applications. dotLRN is also modular in that new course management functionality can be added as desired. Since dotLRN modules must function within the dotLRN architecture, dotLRN modularity must be built on top of OpenACS modularity.

The dotLRN architecture attempts to define a framework within which learning communities develop. A learning community may take many different forms, but remains the crux of the architecture.

Learning Community

• a group: this will serve to define membership and roles within the learning community. These groups are not necessarily all in the same group type (well, they are all ROOTED in the same group type, dotlrn_community).
• a site node: this will serve to define a consistent URL for the learning community, and to segment away each communities from one another. An example is /dotlrn/alumni-1998.
• an instance of the dotLRN Community Manager package: this will serve to display community-specific data in a way that is clearly segmented away from the other learning communities using the acs-subsite constructs.

Class Instances & Clubs

Class Instances

• Year (e.g. 2002)
• Term (e.g. Spring)
• Section (e.g. Section B)
• Start Date
• End Date

Since all class instances have a common basic set of parameters, the class instance groups should all be a single core group type, called dotlrn_class. The dotlrn_class group type defines the attributes above (year, term, section). dotlrn_class is a group type that subtypes dotlrn_community.

In addition, in order to group class instances by the class they refer to, the dotlrn_class group type is subtyped into further group types, where one class is itself a group type. For example, 6.001 is a group type, whose parent group type is dotlrn_class. Then, 6.001 is the group type that all instances of 6.001 belong to. 6.001 - Spring 2002, Section B is a group of group type 6.001. This architecture allows for:

• class-specific attributes in addition to the generic set,
• relating different class instances to a single class,
• reusing existing OpenACS 4 concepts of group memberships and permissions.

Communities (Clubs)

Thus, unlike class instances, the group type structure for clubs can be much simplified. A root group type, called dotlrn_club can encompass all club groups without any additional level of group typing.

dotLRN Packages

Thus, a dotLRN Package is composed of three OpenACS 4 packages:

• an OpenACS 4 raw functionality package whose dependencies are completely independent of the core dotLRN application (e.g. bboard).
• an OpenACS 4 portlet, using the New Portal Architecture (NPA), whose role is to summarize the information in one portlet (e.g. bboard-portlet). This is dependent on the NPA, but not on dotLRN.
• an OpenACS 4 package (e.g. bboard-dotlrn), dependent on the core dotLRN application, whose role is to wrap the raw OpenACS 4 functionality in the required dotLRN APIs.

The relationship between the NPA and the portlet package are defined using ACS Service Contract. This is described in greater detail in The Portal Interface (futher down).

The relationship between dotLRN and the specific dotLRN-dependent packages (dotlrn-bboard, dotlrn-faq, etc...) is also defined using ACS Service Contract. ACS Service Contract defines a standard provider/consumer interface with special contract APIs. The dotLRN system defines the dotLRN Applet Contract, which includes the following operations:

• GetPrettyName: Obtain a pretty, presentable name for the applet in question.
• AddCommunity: Add the applet to a new community. This will most probably entail creating a new package for this functionality, mounted below the community's main mount point. It will also involve setting up applet-specific data structures (e.g. a new forum inside bboard).
• RemoveCommunity: Remove the applet from the community. This will entail cleaning up any applet-specific data structures, removing the mount point and package instance.
• AddUser: add a user to the community, and perform any applet-specific related actions. For applets that are represented via a portlet (which is often, but not always, the case), this will add the right portlet to the user's portal page for that community. It will also add the generic portlet to the user's main, cross-community workspace.

The specifics of creating a dotLRN package are described in the dotLRN Package Creation Guide.

The Portal Interface

The current Portals package is inappropriate for this effort, given that there is no clean API for creating portal pages, setting up portal pages configuration, and rendering portal pages programmatically. Instead, dotLRN will need a much more programmatic portal mechanism.

A Portal Page

• a layout type (3-columns, 2-columns, etc..)
• a set of portlets and their individual configuration information
• a set of permissions for viewing the portal page

The dotLRN application will then create, configure, and associate individual portal pages with specific users' sections of the site. This will allow portal functionality to exist within the dotLRN application without handing over all control to the portals package.

Portlets

• rendering itself within a portal page
• providing a set of editable parameters
• linking to all appropriate features in the underlying OpenACS package

The Per-User Interface

The per-user interface will use slightly different portlets than the community-specific ones, given that those portlets will require scanning information across package instances. There is some thought that this may be "not so kosher." As long as the cross-package information is kept to a minimum, though, it should be just fine. We'll make sure to keep associating packages with the communities they belong to.

<%= [dotlrn_footer] %>