Package Object Types

Created by Dave Bauer, last modified by Gustaf Neumann 02 Jun 2017, at 02:29 PM

This describes the discussion for TIP#120 https://openacs.org/forums/message-view?message_id=1482643

 

APM Packages are all of the same acs_object_type of 'apm_package'.

I propose creating an acs_object_type for each package type as a subtype of apm_package.

This would allow for a hierarchy of package types. The most common example we might think of is dotlrn. The dotlrn package could be a subtype of the subsite package. This would allow an easier way to determine if a package takes on the role of a subsite type package and it could greatly simplify all the code that has to be special-cased to determine if dotlrn is installed.

This would also allow simplification of the case when a new package is created to customize the user interface of another package. For example, many people would like to customize the forums package, to change the style of user interface. If we had a custom-forums package type that was sub-typed from forums, we could have a simple and consistent mechanism to defer pages to the parent package type for handling. This would allow much easier reuse of pages and would make it very simple for local customizations to be handled safely without worrying about accidentally adding custom code back into OpenACS.

 The immediate goal of this work is to make the dotlrn package a subtype of the acs-subsite package. I have done preliminary work to turn dotlrn communities (groups) into application groups of the dotlrn package also. This should make it easier to do an upgrade to an existing dotlrn install that will support subsite based dotlrn.

Previous work includes the https://openacs.org/api-doc/proc-view?proc=subsite%3a%3apackage%5fkeys subsite::package_keys procedure. This basically is a hard coded list of packages that fulfill the subsite role. Defining children of a subsite object_type would allow greatly flexibility and use the existing features of the toolkit.

 Steps to implement

1) Make a new object_type for existing package_types when a new package type is created. Default is subtype of apm_package.

2) Add parameter to package create code to specify package super-type

3) Add tag to info file super-type which is optional and will default to apm_package. This tag will have the same behavior as requires element so Tcl libraries are loaded of the super-type.

4) Add attribute to apm_package_types for inherit_ui_p to specify if URL resolution will go up the package type hierarchy.

5) Update apm_paramaters to support setting parameters for the super-type package parameters up the package type hierarchy. Allow sub-typed packages to override the default value of an inherited parameter.

6) Fix package loading to load Tcl libraries in package dependency order.

 

---

Comments by Don Baccus:

Let's think about UI issues for a moment ... I have an idea to toss out

Currently, abstract URL resolution works like this:

 1. If a file or template at [acs_root_dir]/www/${url_path} exists, return it

2. If a file or template at [acs_root_dir]/packages/[ad_conn package_key]/${url_path} exists, return it

3. 404

 We can extend this if we allow package sub-typing ...

replace 2 with ...

2. set package_key [ad_conn package_key]

2a. while no file exists at [acs_root_dir]/packages/$package_key/$url_path do

2b.   if parent type is apm_package, break, else set package key to parent type's package key

2c. od

2d. if exists - return file or template

In other words, allow for the inheritance of parent package UI.

 Often, of course, this isn't always desirable, so an apm package type would want to have a "don't inherit UI" attribute.  You'd do this, for instance, if you were going to brand new UI for an existing package.  Say ... a portlet.

Inheriting the UI though allows for some things.  For instance, dotlrn could be mounted at /, no need to mount an acs-subsite instance at all as is done now because its UI would already be available (assuming dotlrn was derived from acs-subsite).

How would this impact performance?  Not at all, if the request processor's performance mode is enabled, and when it's not, who cares?

---

Comments by Gustaf Neumann:

Defining package types as acs-object-types and allowing sub-typing/sub-classing for packages using these is a good idea. As presented at the OpenACS conference in Guatemala, xotcl-core and xowiki support this already since about a year. So is it possible to define the s5-package by reusing xowiki in a few lines of code. Other examples were presented by Victor Barrios (mashup) or Stefan.

Subtyping acs-object-types is just the first step, the (desired) implication are something which might need more discussions. Some changes are desirable for the package manager or the request processor.

Note, that in the xo* packages, it is not only the case that packages are object-types, but that package instances are objects (actually xotcl objects), which provide the package instance specific context for a request. Package instance objects are initialized at the begin and deleted at the end of a request.

Below i will use the term "reused package" for the superclass (the more general package) and the term "specialized package" for the subclass (the more specific package, inheriting from the superclass package).

Here are a few items from my experience:

 

1. package loading: if a package reuses an other package via sub-classing, it should load the library files (.../tcl/*tcl) of the sub-classed package as well and initialize it. Daveb, why not use requires tag in the info file? If there is more than one package reusing the same package the library is loaded more than once.
2. package parameters: a specialized package should inherit the package parameter definitions of the reused package(s)
3. per-request files (../www/*) and context management: it is desired/necessary to share some of the per-request files and to allow a per-package-instance initialization (constructor)

For the three issues, the xo* packages use the following strategy:

• package loading:  
  Since the loading order of apm-packages at boot-time is mostly alphabetical, there must be a way to say to load required packages. In particular, the specialized package should load the library files of the reused package (e.g. s5 should load the library files of xowiki) Daveb Would it make more sense to just fix packages to load in required order?
   
  • Working solution in xo*:
    Add a line like the following to e.g. the first loaded file of the s5 package (the specialized package) to indicate the dependency of xowiki (the reused package)
    
    ::xo::db::require package xowiki
    
    This call checks, if the library files of the specified package are already loaded and load it via apm_source, if not (see as well http://alice.wu-wien.ac.at:8000/s5-xowiki-talk-guatemala/presentation?slideshow=1&pagenr=5)
     
  • Desired solution:
    While the working approach works fine with moderate effort, it can be improved via the apm-package manager. It should be possible to specify in the package manager "this package is a subclass of some other package" an add the specialized package automatically to the dependency list. The apm* procs should sort the dependencies in a topological order and load the packages this way. There would be no need to figure out what the first loaded file is, since the order is on the package level. Daveb yes APM needs to have support to specify when you create a package. Roc The topological load order is desirable, but at this moment standard OpenACS mostly just loads the libraries that's why we don't see problems often, while in xo* packages you actually use it for construction, right? (that was the problem I detected). Will be good to use topological for subtypes and package dependencies.
     
• package parameters:
  Without any support, it would be required to replicate the definition of the package parameter of the reused packaged in the specialized package. Extending/altering the package definitions in reused package would have to be repeated as well in all specialized packages (maybe over some specialization levels)
   
  • Working solution in xo*:
    xotcl-core has an object oriented package parameter code that searches parameters on the superclass hierarchy of the specialized package. This leads to several space and speed improvements (see e.g. http://alice.wu-wien.ac.at:8000/s5-xowiki-talk-guatemala/presentation?slideshow=1&pagenr=6 and following pages). The interface of the oo-code mirrors the interface of the classical interface (e.g. parameter get). The implementation does actually more than just searching along a path, it avoids redundancy as far as possible)
     
  • Desired solution:
    The current implementation allows just to share package parameters, if the specialized package actually wants to overwrite some parameters, it cannot do it, since it uses the old shared/parameters?package... scripts, that are not OO aware. So, currently, to alter parameters they have to be copied or the shared/parameter code has to be adapted.  It should be possible alter the default value of a parameter in a specialized package for further inheritance or other instances of a reused package. It is as well desired to add permissions, maybe, not every package admin should be allowed to alter all package parameters (e.g. changing policies in xowiki in a dotlrn-like installation, where package-admins are teachers/lecturers/...) Daveb I think there is a good proposal around to make this work by scoping parameters at the package level or package instance level that would help here. Permissions is an interesting idea but probably more complex than we need to get started. Roc Will be good implement parameter sharing / reuse (and less redundancy) for non-xo* apps.
     
• per-request files and per-instance context management:
  The specialized package will share some files from the reused package (e.g. www/admin), but it also wants to perform some package specific initialization
  • Working solution in xo*:
    the specialized packages use index.vuh files for www and www/admin, all per-request files use ::pkgkey::Package initialize to resolve the context of a package instance and to call the package initialization (see e.g. http://alice.wu-wien.ac.at:8000/s5-xotcl-core-tutorial/presentation?slideshow=1&pagenr=66 and http://alice.wu-wien.ac.at:8000/s5-xotcl-core-tutorial/presentation?slideshow=1&pagenr=79 from the xotcl-core tutorial).

    An example for the redirector is https://raw.githubusercontent.com/openacs/s5/master/www/admin/index.vuh

    The approach with index.vuh works quite well, since physical existing files override the virtual (index.vuh) redirect. So, all per-request files in www/* in the specialized package, which should be different from the reused package, can be put to the www/* directory of the specialized package (e.g. s5). Not sure, how this approach works over multiple specialization levels.
     

  • Desired solution:
    As Don points out, the search for files could be done automatically by the request processor in case the package is a specialization of another package. This approach has no problems with multiple specialization levels. One has to sort out as well the interactions of .vuh files and package hierarchy search. Roc The request-processor solution is the best and cleaner.
    
    It is as well desirable to call from the request-processor the package specific initialization DAVEB. What is a package specific initialization? This seems to refer to xowiki based packages that have initialization procedures that setup the context for the request. I believe this is not a core feature yet.

Migration from CVS to GIT

Created by Victor Guerra, last modified by Gustaf Neumann 02 Jun 2017, at 01:17 PM

IMPORTANT!!! by no means the statements written in this page are official. At the moment one should consider this information just and only for experimental purposes. There are no official decisions made by the OCT so far regarding migration to GIT or any other source control tool.  At the moment CVS is the official tool used and you can navigate the project history and code at our official code and history inspector Fisheye OpenACS

Tools to consider for the migration:

• GIT includes a tool for the migration of CVS repositories called git-cvsimport.
• The cvs2svn project provides support for converting a CVS repository into GIT. The tool is called cvs2git

Structure of the GIT Repository:

• One git repository hosting the entire code base of OpenACS (including contrib and all packages) vs. multiple repositories (provide separate git repositories managed via modules/subdirs/...)
• A single large repository seems not realistic, since many sites have site-speciifc modules, since there projects like ProjectOpen and others having developed a long range of maintained packages. But are 300+ separate repositories manageable with reasonable effort (maybe mr is currently the best option, we have good experiences with this). However, this decision has large impact on tagging and release management (see below)

Where could the repositories live (?):

• Official repositories on openacs.org machine? Having remote-mirrored repositories on github so developers can clone and share patches using github. -- jiml: many tools which could get similar function to github (forking, pull requests),,,  can we put up a gitorious on a test site with maybe 50gb of repo space so all the committers can have their own?
• Using github.com as our official source code site? or Bitbucket?

Points to consider before | when migrating to GIT: 

• Release-management: Installing-software-from-repository code is based on release "channels" and cvs-tags in order to define which channels are available to users ( https://openacs.org/repository/) and to provide the recent packages for that channel.  In principal, similar tags could be used as well in git, but there are several differences. CVS tags are per file, git tags are per repository (if the git repository contains e.g. all packages, there is no way to tag a single package as e.g. OpenACS 5.9 compatible with e.g. tag "openacs-5-9-compat"). It is possible to work with separate git repositories and work with git modules and/or subtrees, but this means that we have 300 repos to manage (all could have separate branches and tags), and single commits covering multiple repos are not supported). This means, that one needs higher level tools and recommended workflows to manage developments on the core source repositories (branches, tags) and site-specific packages and local modification as well as site-specific release and feature branches
• Depending on the decision of the structure it is necessary to provide git-guidelines similar to cvs-guidelines and the code retrieving and generating .apm packages has to be rewritten.
• Application for voting on oct-elections depends on commits history ( most likely this will transparent since we use fisheye.openacs.org  for fetching information about commit history, and fisheye provides one and one only interface for querying data, so the fact that the code is being controlled by cvs or git is irrelevant ... but since fisheye is configured for CVS, it has to be newly built for the resulting infrastructure, or it has to be dropped/replaced by github/bitbucket or others.

Current state:

• Since 2014 Victor Guerra (Vienna University of Economics) has created an unofficial mirror on github https://github.com/openacs which contains a daily mirror of the CVS repositories at openacs.org. It consists of an openacs-core modules plus a separate repository for every non-core package.

WCAG 1.0 Checkpoints

Created by Emmanuelle Raffenne, last modified by Gustaf Neumann 02 Jun 2017, at 09:06 AM

Status at 21 october 2008 (OpenACS 5.4.3 and .LRN 2.4.1)

A summary for US Section 508 is available at LINK_TO_WIKIPAGE 

See Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0 for details

How to read this document

Accessibility Compliance Level

• Level A means that all the priority 1 checkpoints are in state "Y" or "n/a".
• Level AA means that level A has been reached + all the priority 2 checkpoints are in state "Y" or "n/a"
• Level AAA means that level AA has been reached + all the priority 3 checkpoints are in state "Y" or "n/a"

Checkpoint Status

• Y: 100% of the pages comply with the checkpoint or the exceptions are clearly identified and listed in the accessibility statement.
• N: NOT 100% of the pages comply with the checkpoint, exceptions are NOT identified.
• n/a: the situation described in the checkpoint is not applicable in ANY of the pages

OpenACS-specific Techniques for Checkpoints

Each checkpoint is identified with a number which links to the OpenACS-specific techniques to apply it.

 

Note: the  links are dead right now, but will point to OpenACS-specific techniques to implement them.

Priority 1 checkpoints

In General (Priority 1)	Yes	No	N/A
1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.	Y
2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup.	Y
4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).	Y
6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.	Y
6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes.			n/a
7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker.	Y
14.1 Use the clearest and simplest language appropriate for a site's content.		N e.g.: portlet
And if you use images and image maps (Priority 1)	Yes	No	N/A
1.2 Provide redundant text links for each active region of a server-side image map.			n/a
9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.			n/a
And if you use tables (Priority 1)	Yes	No	N/A
5.1 For data tables, identify row and column headers.	Y
5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.	Y
And if you use frames (Priority 1)	Yes	No	N/A
12.1 Title each frame to facilitate frame identification and navigation.	Y
And if you use applets and scripts (Priority 1)	Yes	No	N/A
6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.		N lorsm
And if you use multimedia (Priority 1)	Yes	No	N/A
1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation.			n/a
1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.			n/a
And if all else fails (Priority 1)	Yes	No	N/A
11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.		N lorsm

Priority 2 checkpoints

In General (Priority 2)	Yes	No	N/A
2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text].	Y
3.1 When an appropriate markup language exists, use markup rather than images to convey information.	Y
3.2 Create documents that validate to published formal grammars.	Y
3.3 Use style sheets to control layout and presentation.	Y
3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values.		N calendar
3.5 Use header elements to convey document structure and use them according to specification.	Y
3.6 Mark up lists and list items properly.	Y
3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation.	Y
6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page.			n/a
7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off).	Y
7.4 Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.	Y
7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects.	Y
10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.	Y
11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.	Y
11.2 Avoid deprecated features of W3C technologies.	Y
12.3 Divide large blocks of information into more manageable groups where natural and appropriate.			n/a
13.1 Clearly identify the target of each link.	Y
13.2 Provide metadata to add semantic information to pages and sites.	Y
13.3 Provide information about the general layout of a site (e.g., a site map or table of contents).	Y
13.4 Use navigation mechanisms in a consistent manner.	Y
And if you use tables (Priority 2)	Yes	No	N/A
5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).	Y
5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting.	Y
And if you use frames (Priority 2)	Yes	No	N/A
12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone.	Y
And if you use forms (Priority 2)	Yes	No	N/A
10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned.	Y
12.4 Associate labels explicitly with their controls.	Y
And if you use applets and scripts (Priority 2)	Yes	No	N/A
6.4 For scripts and applets, ensure that event handlers are input device-independent.	Y
7.3 Until user agents allow users to freeze moving content, avoid movement in pages.			n/a
8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]	Y
9.2 Ensure that any element that has its own interface can be operated in a device-independent manner.			n/a
9.3 For scripts, specify logical event handlers rather than device-dependent event handlers.	Y

Priority 3 checkpoints

In General (Priority 3)	Yes	No	N/A
4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs.		N
4.3 Identify the primary natural language of a document.	Y
9.4 Create a logical tab order through links, form controls, and objects.		N
9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls.		N
10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.	Y
11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)	Y
13.5 Provide navigation bars to highlight and give access to the navigation mechanism.	Y
13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.		N
13.7 If search functions are provided, enable different types of searches for different skill levels and preferences.		N
13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc.			n/a
13.9 Provide information about document collections (i.e., documents comprising multiple pages.).	Y
13.10 Provide a means to skip over multi-line ASCII art.			n/a
14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page.			n/a
14.3 Create a style of presentation that is consistent across pages.		N
And if you use images and image maps (Priority 3)	Yes	No	N/A
1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map.			n/a
And if you use tables (Priority 3)	Yes	No	N/A
5.5 Provide summaries for tables.		N
5.6 Provide abbreviations for header labels.		N
10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns.		N
And if you use forms (Priority 3)	Yes	No	N/A
10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.		N

Install ProjectOpen

Created by Robert Taylor, last modified by Gustaf Neumann 01 Jun 2017, at 10:14 AM

See http://www.project-open.com/en/list-installers

Search

Created by Robert Taylor, last modified by Gustaf Neumann 01 Jun 2017, at 10:10 AM

Package Specification Summary for Package: search

Summary:	Site wide search
Description:	Site wide search implemented with service contracts, currently supports PostgreSQL via the tsearch2 driver and Oracle via the intermedia-driver.
Documentation:	Package Documentation
Maturity:	Mature and Standard
This package depends on:	acs-service-contract acs-tcl acs-templating acs-automated-testing
Packages that depend on search:	acs-content-repository intermedia-driver tsearch2-driver
Package parameters:	FtsEngineDriver Which search engine driver to use? You should enter the name of the related binding (e.g. openfts-driver, swish-driver,...) (default tsearch2-driver, type number, scope instance) LimitDefault Default limit value (default 10, type number, scope instance) PagesPerGroup Number of pages in a page group (default 10, type number, scope instance) SearchIndexerInterval Interval in seconds for the search indexer to sweep for new or updated items. (default 31, type number, scope instance) SearchTheWeb Search the Web (e.g. Google) (default http://www.ask.com/web?q=%s Ask.com http://www.bing.com/search?q=%s Bing https://duckduckgo.com/?q=%s DuckDuckGo https://www.google.com/search?q=%s Google https://twitter.com/search?q=%s Twitter http://search.yahoo.com/search?p=%s Yahoo!, type string, scope instance) SubsiteSearchP If mounted in a subsite should the search be restricted to items in the subsite by default. Requires that package_id in acs_objects be properly populated. (default 0, type number, scope instance) Symbol2Interval Translate symbol to date interval. (default m3 {3 month ago} m6 {6 month ago} y1 {1 year ago}, type string, scope instance) Syndicate Should syndication data be stored when indexing for search. (default 0, type number, scope instance) ValidateCSRFP Boolean parameter to activate/deactivate CSRF protection for this package instance (default 1, type number, scope instance)

Bug Tracker Summary for Package: search

Open Bugs:	8
All Tracked Issues:	29
Latest Bug Opened:	2017-06-03 context snippet might contain truncated markup
Latest Bug Fixed:	2024-10-13 Search observer queue may have NULL entries.
Top Bug Submitters:	Christian Brechbuehler (5) Eduardo Santos (3) Ryan Gallimore (3) Daniël Mantione (2) Jeff Davis (1)
Top Bug Fixers:	Gustaf Neumann (9) Dave Bauer (8) Jeff Davis (1) Lars Pind (1) Tilmann Singer (1) Alfred Werner (1) Maurizio Martignano (1)

Code Metrics Summary for Package: search

# Tcl Procs	26
# Tcl Lines	889
# Tcl Blank Lines	112
# Tcl Comment Lines	129
# Automated Tests	0
# Stored Procedures	PG: 2 ORA: 4
# SQL Lines	PG: 273 (blank 38 comments 20) ORA: 389 (blank 61 comments 81)
# ADP pages	4
# ADP lines	144
# Include pages (search/lib/)	2
# Documentation pages	2 (Package Documentation)
# Documentation lines	172
Browse Source	API-browser
Github Repository:	https://github.com/openacs/openacs-core

For details concerning the intermedia-driver,  see David Bauer's post 12.  The intermedia-driver itself states that it requires Oracle 8.1.7, may work with 9, will NOT work with Oracle 10.

Summary

The aim of the project is to create a user-friendly, extensible, and scalable search package. The project team consists of Dirk Gomez (co-lead), Deirdre Kane (co-lead), and Dave Bauer. MIT Sloan is the lead .LRN institution for this project.

There currently is no working search solution for .LRN. The document below describes how to implement a search package for .LRN for Oracle 8i, which is the database system in use in MIT Sloan School. The described approach should be portable to PostgreSQL.

Packages/portlets used by Sloan

A User may have these portlets:

• News
• Useful Links (custom portlet)
• Links
• Day Summary
• Full Calendar
• Documents
• Surveys
• Forums
• Frequently Asked Questions

A class may have these portlets.

• Class Info
• News
• Frequently Asked Questions
• Forums
• Syllabus
• Staff List
• Schedule
• Subgroups
• Survey
• Full Calendar
• Documents
• Calendar
• Homework
• Assignments
• Lectures Notes and Slides
• Handouts and Study Materials
• Trading Game

A communitiy may have these portlets:

• News
• Frequently Asked Questions
• Survey
• Forums
• Subgroups
• Documents
• Members
• Full Calendar
• Community Info
• Calendar
• Schedule
• Syllabus
• Trading Game

Portlets/packages not indexed

• Trading Game
• bookmarks
• curriculum
• news-aggregator
• blogger

Work on packages

To be reviewed

• faq
• survey
• static

First draft programmed

• calendar
• curriculum
• dotlrn

Pending

• File-storage
• news

Per-Package docs and comments

FAQ

Index questions and answers and index FAQs separately.

Forums

Index messages and forum title charter separately.

Content-Repository

See this Forum thread

Open Questions and Tasks

Should we use triggers for indexing content? Contrast portability, stability, plugin-ability.

Read up on doc_highlight

Maybe store the community_id in the intermedia content?

 

 

 

OpenACS/LAMP Comparison

Created by Talli Somekh, last modified by Gustaf Neumann 30 May 2017, at 09:16 PM

Introduction
OpenACS
LAMP
Comparisons

Introduction

The OpenACS and LAMP represent approaches to developing large scale web enabled database applications. Both have a very strong track record of enabling developers to quickly and efficiently build websites with complex functionality while still maintaining high performance. The are significant differences between the two, however. This article attempts to address these differences and why the OpenACS is a preferred approach to developing scalable, complex web applications.

 

Note: This article assumes the use of a Unix-oriented operating system for both toolkits such as Linux, FreeBSD or Solaris. The use of Microsoft Windows is outside the scope of the discussion.

OpenACS

The OpenACS is a framework for developing web applications. It is characterized by a specific set of components around which a group of developers have spent nearly 10 years developing a stable data model and a set of business logic for reuse in user-oriented, data-centric web applications. A free and open source project released under the GNU General Public License, the OpenACS can be thought of as consisting of four components:

 

Web Application Server

The OpenACS uses AOLserver, a high performance web application server that has been proven in perhaps the most highly used environments on the web as it runs AOL.com, Netscape.com, MovieFone.com, Mapquest.com and other major web properties. AOLserver is a unique combination of efficient database connection pooling, native database APIs and an easy to use embedded scripting language called Tcl. This collection of features make it a very powerful rapid web development environment.

 

Relational Database Management System

Originally written for Oracle, the industry leading RDBMS, the OpenACS now uses either Oracle or PostgreSQL, the most advanced open source relational database. Both systems offer excellent performance, stability and features that the OpenACS community leverages to create complex data driven applications. These features include native atomic transactions, foreign key constraints and native procedural languages.

 

OpenACS Business Logic and Data Model

The truly unique component of the OpenACS is the time tested business logic and data model. These components have been in development and use for nearly 10 years and have seen over $50M of investment in their design, documentation and implementation. The components include a well defined and flexible templating language, extensive user registration, extremely powerful permissioning model and well considered security and authorization mechanisms. In addition, the OpenACS provides mechanisms for data input validation and automated testing among other things. These foundations provide developers with the ability to rapidly create and deploy packages such as forums, portals or a customized application.

The business logic of the OpenACS is written in Tcl, a popular scripting language that is embedded in AOLserver. Tcl is not as popular in the web development world as its "P" cousins, but it is a very well known and extensive scripting language. It is marked by a very shallow learning curve, simple syntax and excellent performance. Used, of course, by AOL for its web properties, Tcl also is heavily used in the networking world (Cisco uses it as the embedded language for its router hardware) and in the automated testing industry.

 

Community

The OpenACS has a large, focused and committed community of developers and users. The community consists of individuals, corporate vendors and institutional users. Some of the users include very influential organizations such as Greenpeace International, MIT's Sloan School of Management and the E-LANE consortium - a group of organizations in Latin and Spanish speaking nations collaborating as part of a grant from the European Union. Openacs.org is the nexus for this community to develop new tools, share experience and assist one another.

Support, training, and documentation are typical points of comparison between open-source and proprietary platforms, and rightly so. In this comparison, OpenACS comes out quite well in many areas. In some cases, users have assessed the level of support and basic documentation available for free from the community as superior to that from commercial vendors or from other open-source systems.

LAMP

The LAMP approach to web development is similar in scope but a different approach than the OpenACS. While the OpenACS is a framework that has a specific standard and focus, LAMP is far more open and represents many different approaches.

 

 

Apache

Apache is perhaps the most successful open source software project in the industry, running nearly two thirds of the sites on the web. It has proven itself in very demanding environments as a stable and flexible tool. It focuses on performing a single task, namely the processing of requests from web clients.

 

MySQL

MySQL is a popular free and open source database that has gained recognition for its friendly slant towards new developers and for its performance. It is well documented and has been used in many web applications and web sites.

 

Perl/PHP/Python

The final component of a LAMP system is a scripting language such as Perl, PHP or Python. Each language has a passionate and well developed community. They are all well documented and have a excellent track records where they have been used to deploy systems. Each has a module that acts as a web application server for Apache (e.g. mod_perl). Each language has a number of application frameworks that are independent but can be connected to one another fairly easily. For instance, Drupal can be connected with phpBB and OScommerce to create a CMS, bulletin board and ecommerce website.

 

Community

The LAMP community is indeed very large. There is a great number of books and websites dedicated to explaining how to use various components to create an application. Orielly's onLAMP.com is one such resource.

The sheer number of companies, individual developers and other resources makes the LAMP platform secure in its longevity. A customer will not have a difficult time finding developers who are familiar with its components or developers who can become familiar with the components quickly.

Comparisons

 

AOLserver vs Apache

The comparison of AOLserver and Apache is probably better explained as the comparison of AOLserver and Apache+mod_perl+mod_dbi. In other words, AOLserver's is a clean and simple integration of the equivalent of three separate Apache products - the web server, the application server and the database connector. In addition, AOLserver's multi-threaded architecture and database connection pooling provides very efficient performance in data intensive applications.

For instance, AOL uses AOLserver in their largest properties to process requests millions of simultaneous, data intensive requests. With a very simple Tcl script calling native database APIs that can access the first available database connection in the pool, AOL can easily manage sites like Moviefone.com, DigitalCities.com and Mapquest.com

Apache plus an application server module can certainly manage a similarly large site as many have proven. However, the administrative overhead of running multiple services is not as elegant as the AOLserver architecture. There are those, however, that prefer such a separation of web and application server in what is called a "multi-tiered architecture."

The OpenACS community believes that the efficiency gains - in terms of stability, performance and administrative ease - of an integrated web application server we've never felt the attraction of migrating to Apache.

 

PostgreSQL or Oracle vs MySQL

MySQL is perhaps the most popular open source SQL database in the free and open source software world. It is marked by being very well documented, tested in various real world applications and excellent performance for web applications. The community is quite healthy and the database seems to be improving.

The OpenACS was originally developed for Oracle and so it relies heavily on database features that only recently MySQL has begun to address. These features include native transaction atomicity (that is, a command is either completed or it is not - there is no halfway), foreign keys (data that is related to another table is consistent and that consistency is always enforced) and a procedural language which assists in the writing of complex data queries. It has always been the opinion that these items, in addition to others, are so critical for the integrity of the data of the application that we will not use MySQL until all of them have been implemented as first class features.

However, MySQL has achieved a great deal of popularity despite what we consider to be serious limitations. This popularity is due to the fact that MySQL has performed exceedingly well when developers have written applications that compensate for such shortcomings, in cases where the data stored is transient or data integrity is not as critical a characteristic for the application as performance.

Luckily, there is another free and open source database called PostgreSQL that not only conforms to the principles that the OpenACS community considers critical but has proven to be as performant as MySQL in real world scenarios. It has native transaction atomicity, supports foreign keys and has a number of procedural languages to choose from, including one that is a clone of Oracle's (which helps us maintain support for both databases.) PostgreSQL also continues to prove itself in demanding environments, including running the .ORG and .INFO registries.

As a result, we feel that in using PostgreSQL for the OpenACS, we have the best of both worlds - a free and open source database that is high performance and flexible while providing us with first-class data security and integrity.

(As a note, MySQL does have support for transactions and foreign keys with an external module called InnoDB. But these features are not turned on by default and they are not native. MySQL 5 promises to change both flaws, but it is not suitable for production use at this time, neither does it fix the absence of a quality procedural language..)

The OpenACS Business Logic and Data Model vs Perl/PHP/Python

This is perhaps the most difficult comparison to make because the items are not the same. The OpenACS is a framework that is written in Tcl because AOLserver is an excellent product that happens to have Tcl as an embedded scripting language. LAMP applications are often written because the developers' have a preference for Perl, PHP or Python.

The best comparison that can be made, then, is which approach provides the most consistency, stability and maintainability for the developers. The OpenACS is a foundation upon which complex applications can be built using a shared data model and reuse of standard components like a templating system, workflow and content repository. Most importantly, the permissioning infrastructure provides a way to design, build and administer secure data driven applications.

There are many similar applications in the LAMP world (Drupal, BinaryCloud, Midgaard, Typo3) but none of them have the track record or the fundamentally sound data model as the OpenACS. Furthermore, each only addresses part of the problem, either as a content management system, as a bulletin board application or an ecommerce package.

As a result, developers in the LAMP world often find themselves developing from first principles over and over again. This means that each time they develop a new system, they design the basic data model for user registration, authentication, content management, etc and then begin gluing different tools together. Even with excellent code repositories like CPAN for Perl for Perl or PEAR for PHP these efforts are usually ad hoc. They also lack a permissioning infrastructure that can manage the overall security of the application.

For instance, taking a content management system like Drupal, a bulletin board system like phpBB and an ecommerce package like OScommerce, each of which is extremely well built in their own right, but the developer must design a way to share each respective application's idiosyncratic data representation.

The OpenACS' shared data model, templating system and service oriented model allows for developing such a system much easier. The standard data model, presentation code and information processing facilities allows the developer to quickly cobble together a stable, powerful and maintainable application. Most importantly, the well designed and tested permissioning infrastructure allows developers to build very flexible and secure data-driven applications.

 

OpenACS vs LAMP communities

The LAMP community as a whole certainly dwarfs the OpenACS community. Considering that LAMP represents an approach including three or four languages vs the OpenACS which is a focused community, this is not surprising.

This is certainly a strength of LAMP. The fact that it is very simple to find developers who are familiar with each tool rather than a framework is something that a user should consider when selecting a software tool. The plentiful documentation is also extremely heartening.

The OpenACS community, however, is very successful and flourishing. There are over 25 international institutions that have deployed .LRN, the free and open source course management system. There are over 20 vendors listed on the OpenACS.org home page offering commercial support. The OpenACS forums and IRC channel is very active as developers discuss ways to enhance the framework.

The LAMP approach includes hundreds or thousands of different platforms. What this means for any specific LAMP solution is that it may draw from a broader library of other programs, but the list of actually tested, integrated pieces and of dedicated developers may be much smaller. LAMP developers are fragmented across many projects, but OpenACS holds the lions share of attention for its technologies and resists community splintering remarkably well.

While the LAMP community is much larger, the OpenACS has established itself in a community of users where technical proficiency and stability is most important. Due to and for this reason, the OpenACS community is vibrant and healthy.

 

---

The author would like to thank the following people for helping with this document: Joel Aufrecht, Dave Bauer, Carl Blesius, Cesar Brea, Bruno Mattarollo and Alfred Werner.

---

Copyright (c) 2004 Talli Somekh

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

Host Node Map

Created by Gustaf Neumann, last modified by Gustaf Neumann 30 May 2017, at 02:28 PM

The host-node-map (see /acs-admin on your OpenACS installation) is a means to map virtual host names to sub-sites or to applications. Depending on the type of mapping, different options are available.

If one maps for instance a host name to an application package instance (i.e. the root url of the application is seen under / under host-node-mapped name, then site-wide services (such as search, register, site-wide administration) might or might not be available. If one want's to offer services to non-registered users, this might be perfectly fine.

When the mapping is against a sub-site, all sub-site services will be available (e.g. /register). This type of mapping can be useful for typical virtual host setups, where different sub-sites might be equipped with different themes.

In order to setup a host-node-mapping, one has to provide multiple names (typically DNS entries) for the same machine and to define then under /acs-admin the association between host names and site nodes.

The setup is influenced by a few parameters such as UseHostnameDomainforReg and CookieDomain. When UserHostnameDomainforReg is set true (default: false), all registrations initiated at the sub-site will be redirected to the main site. In these cases, the login cookie will be issued by /register for the main site, unless the CookieDomain is set appropriately. It is currently not supported to register users on completely different domains (not sharing a common root owned y the site master).

The situation with a host-node mapping to application packages is very similar to the last paragraph. Also in these cases, the /register url (generated via ad_get_login_url) will be mapped to the nearest sub-site, which might be the main site.

When using host-node-maps, don't use mixed HTTP/HTTPS setups based on RestrictLoginToSSLP. Also the usage of the (recommended) Strict-Transport-Security setting (setup via the NaviServer config file, see e.g. openacs-config.tcl) might interfere with RestrictLoginToSSLP. So the usefulness of the parameter is nowadays somewhat limited. The general trend is to use HTTPS for the full site (and all sub-sites as well).

for everyone - Table of Contents

Created by OpenACS community, last modified by Gustaf Neumann 30 May 2017, at 09:30 AM

docs-end-user 

    openacs-system
        openacs-subsystem
        tcl
        aolserver
        postgresql
        oracle

    community-culture

    Documentation_Project

    docs-history

    doc-credits
 

Project Manager

Created by Robert Taylor, last modified by Gustaf Neumann 30 May 2017, at 09:06 AM

The project manager package is used to log and track various aspects of projects in 3 typical (default) relationship categories of users (members): Leads, Participants and Watcher.

The project manager uses the Logger package to log hours and expenses by default. Any other units can be created and looged as need.

.LRN Leadership Team 2008

Created by Carl Robert Blesius, last modified by Gustaf Neumann 01 May 2017, at 09:55 AM

This is the appointed Leadership Team for the year 2008. The Leadership Team is self elected from .LRN consortium and community members as outlined in the .LRN Governance Document.

• Avni Khatri
• Dave Bauer
• Don Baccus
• Emmanuelle Raffenne
• Gustaf Neumann
• Nima Mazloumi
• Olga C. Santos
• Raúl Morales Hidalgo
• Victor Guerra
• Dario Roig