Weblog Page

Oracle

Created by OpenACS community, last modified by Robert Taylor 07 Aug 2006, at 03:21 AM

Oracle

Oracle is an enterprise level, ACID-compliant RDBMS

What others say about Oracle

OpenACS uses Oracle with PL/SQL

• http://en.wikipedia.org/wiki/PL/SQL
• http://www.oracle.com/technology/tech/sql_plus/

Mail Transport Agents

Created by OpenACS community, last modified by Robert Taylor 07 Aug 2006, at 03:20 AM

a program that handles all incoming and outgoing mail. The Reference Platform uses Qmail; any MTA that provides a sendmail wrapper (that is, that can be invoked by calling the sendmail program with the same variables that sendmail expects) can be used with OpenACS.

This is a placeholder for notes implementing specific MTAs with OpenACS

Installing OpenACS on SuSE

Created by OpenACS community, last modified by Robert Taylor 07 Aug 2006, at 03:20 AM

Should you decide to Install OpenACS from source using general en:openacs-system-install instructions, refer to these notes for changes:

Installing [en:postgresql

Set PostgreSQL to start on boot

[root ~]# cp /var/tmp/openacs-5.2.0d1/packages/acs-core-docs/www/files/postgresql.txt /etc/init.d/postgresql
[root ~]# chown root.root /etc/init.d/postgresql
[root ~]# chmod 755 /etc/init.d/postgresql

Test the script.

[root ~]# /etc/init.d/postgresql stop
Stopping PostgreSQL: ok

If PostgreSQL successfully stopped, then use the following command to make sure that the script is run appropriately at boot and shutdown.

[root ~]# cd /etc/init.d
root:/etc/init.d# ln -s /etc/init.d/postgresql K20postgresql
root:/etc/init.d# ln -s /etc/init.d/postgresql S20postgresql  
root:/etc/init.d# cp K20postgresql rc2.d
root:/etc/init.d# cp S20postgresql rc2.d
root:/etc/init.d# cp K20postgresql rc3.d
root:/etc/init.d# cp S20postgresql rc3.d
root:/etc/init.d# cp K20postgresql rc4.d
root:/etc/init.d# cp S20postgresql rc4.d 
root:/etc/init.d# cp K20postgresql rc5.d
root:/etc/init.d# cp S20postgresql rc5.d
root:/etc/init.d# rm K20postgresql
root:/etc/init.d# rm S20postgresql
root:/etc/init.d# 

Test configuration.

root:/etc/init.d # cd
root:~ # /etc/init.d/rc2.d/S20postgresql start
Starting PostgreSQL: ok
root:~ # 

Installation - Req.

Created by OpenACS community, last modified by Robert Taylor 07 Aug 2006, at 03:19 AM

Installation Documentation Requirements

By the OpenACS Community. This section is a collection of documentation requirements that have been expressed in the OpenACS forums to 4th July 2003.

OpenACS installation documentation should meet the following requirements. No significance has been given to the order presented, topic breadth or depth here.

• state installation prerequisites. For example: "You should read through the installation process to familiarize yourself with the installation process, before beginning an installation."

• list critical decisions (perhaps as questions) that need to be made before starting: which OS, which DB, which aolserver version, system name, dependencies et cetera. Maybe summarize options as tables or decision-trees. For example, "As you proceed throughout the installation, you will be acting on decisions that have an impact on how the remaining part of the system is installed. Here is a list of questions you should answer before beginning."

• list pre-installation assumptions

• Show chronological overview of the process of installing a system to full working status: Install operating system with supporting software, configure with preparations for OpenACS, RDBMS(s) install and configure, Webserver install and configure, OpenACS install and configure, post-install work

Developer - Requirements

Created by OpenACS community, last modified by Robert Taylor 07 Aug 2006, at 03:13 AM

Developers - Documentation Requirements

By the OpenACS Community. This section is a collection of documentation requirements that have been expressed in the OpenACS forums to 4th July 2003.

OpenACS developer documentation should meet the following requirements. No significance has been given to the order presented, topic breadth or depth here.

• list documentation assumptions, such as familiarity with modifying OpenACS packages. All kernel docs are here etc.

• This documentation should be written for ongoing use by developers, not as a tutorial.

• List of practical development and diagnostics tools and methodologies.

• List of OpenACS development resources, api-doc, schema-browser, developer-support package etc.

• Identify each OpenACS subsystem, explain why it is used (instead of other choices). In the case of subsystems that are developed outside of OpenACS such as tcl, include external references to development and reference areas.

• Show current engineering standards and indicate where changes to the standards are in the works.

• Sections should be dedicated to DotLRN standards as well, if they are not available elsewhere.

• Add overview diagrams showing the core parts of the datamodel including an updated summary of Greenspun's Chapter 4: Data Models and the Object System

• package design guidelines and development process templates including planning, core functions, testing, usability, and creating case studies

• Standard package conventions, where to see "model" code, and guidelines (or where to find them) for:

  • programming tcl/sql

  • using the acs-api

  • ad_form

  • coding permissions

  • OpenACS objects

  • scheduled protocols

  • call backs

  • directory structure

  • user interface

  • widgets

  • package_name and type_extension_table

  • adding optional services, including search, general comments, attachments, notifications, workflow, CR and the new CR Tcl API

• Document kernel coding requirements, strategy and guidelines to help code changers make decisions that meet kernel designers' criteria

Deployment feedback channel

Created by Aernout Schmidt, last modified by Robert Taylor 07 Aug 2006, at 03:13 AM

Pupose: A channel for sharing heuristics found in the installation and deployment of OpenACS and its packages.   

1. It may be useful to remember that after successful install of packages like Lars-blogger or Xowiki any content added for testing puposes can (and soon will) be scooped by search engines and/or broadcasted by rss feeds and will thus remain available to the public (and make it avoid your service) for a long time. Parameters and permissions are (often) open by default. Check them first.

2. In version 5.2.2 not very many packages are available. On the other hand, in version 5.1.5 some 5.2.2-packages won't work (dotFOLIO). Several 5.1.5-packages will work onder 5.2.2, if first installed on 5.1.5 and subsequently upgraded to 5.2.2. My current (admittedly Project Open is not yet very well tested) list:

   Services

   Applications

   ACS Reference Data 5.2.2 API Browser 5.2.2 Ajax Helper 0.3d Attachments 0.10 Authentication 5.2.2 Automated Testing 5.2.2 Bootstrap Installer 5.2.2 Categories 1.1 Clickthrough 0.1d Clipboard 0.1d Content Repository 5.2.2 Date and Time Utilities 5.2.2 Documentation 5.2.2 Dynamic Object Type 0.1 Events 0.5 Feed Parser 0.3d Kernel 5.2.2 Localization 5.2.2 Mail 5.2.2 Mail Services Lite 1.0 Messaging 5.2.2 New Portal 2.1.2d2 Profile Provider 2.1.1 RSS Support 0.3 Reference Data - Timezone 5.2.2 Related Items 0.1d Service Contracts 5.2.2 Site-Wide Administration 5.2.2 Subsite 5.2.2 Tcl Library 5.2.2 Templating 5.2.2 Trackback 0.1 Tsearch2 Driver 0.4d2 User Preferences 0.5d3 Views 0.1d Workflow 2.1.1 XML-RPC Server 0.3 XOTcl Core 0.37 edit-this-page Portlet 2.0.3 webDAV Support 1.1b1

   Calendar 2.1.0b4 Edit This Page 1.8 FAQ 4.7.4 File Storage 5.2.2 Forums 1.2.0d3 GateKeeper 4.0b General Comments 5.2.0 News Aggregator 1.0.2 Notifications 5.2.0 Project/Open Core 3.0.0 Project/Open Cost Core 3.0.0 Project/Open Filestorage 3.0.0 Project/Open Forum 3.0.0 Project/Open Freelance 3.0.0 Project/Open HR 3.0.0 Project/Open Invoices 3.0.0 Project/Open Payments 3.0.0 Project/Open Timesheet Management 3.0.0 Project/Open Translation 3.0.0 Project/Open Translation Invoices 3.0.0 Robot Detection 4.0.1 Search 5.2.2 User Profile 2.1.1 Weblogger 2.2.0 Workflow Service (Petri Nets) 4.5 dotFOLIO 0.3 dotFOLIO UI 0.3 xowiki 0.26

    
    I have an operational site now and have forgotten to install the Simulation package in the 5.1.5 stage. Correcting this will be time consuming.   

Getting help

Created by Jade Rubick and OpenACS community, last modified by Torben Brosten 16 Jul 2006, at 10:18 PM

Introduction to the OpenACS Community

How to get help from the OpenACS community most effectively.

by Jade Rubick

OpenACS is more than a technology, it is a vibrant community. If you are new to OpenACS.org, you are coming into this community as a newbie, or a new person. The OpenACS folks are extremely helpful. However, consider what resources you have available for getting information most effectively.

Communities work similarly to how a bank account works. You make deposits by doing things that are beneficial to the community, and you make withdrawals by doing things that take time and energy from the community. The more helpful you are, the more people are going to be willing to help you out. If you have a pattern of being demanding and unhelpful, people are less likely to help you as much. This is not a conscious effort to punish, but common social equitable practices. It is just how people tend to participate in general.

What have you to offer?

What have you to offer the community? You are new, so maybe you cannot offer much in the way of technical knowledge. Can you trade for detailed technical help from more knowledgeable individuals?

1. If there is no documentation for what you're trying to do, then the single most helpful thing you can do is write documentation as you learn. Use documentation to both keep track of what you’ve learned, and as a way of sharing that knowledge with others. It is also something you can trade for the time of more experienced developers. They know that if they help you out, you'll write up documentation for it, and they might not have to answer that question again.
2. As you find bugs, you can file them in the OpenACS bug-tracker.
3. If you have a particular project in mind, or something you're planning on creating, then building that project and sharing it with the community is good incentive for people to help you. They may be interested in what you're building.
4. When a newer newbie asks a question you know the answer to, answer it! Many OpenACS developers budget out a certain amount of time a day to help the general community. This builds goodwill, strengthen the platform you're using, and helps those users become more knowledgeable so they can contribute to the community.
5. As a newcomer, you have a unique perspective to OpenACS. You can often see deficiencies and areas to improve that old-timers might not even notice. Feel free to bring them up as suggestions. Remember that the OpenACS community is a community, not a company. It isn't their responsibility to fix things for you, or make them better. But it is often in their self-interest to improve things, and they will. Flames won't get you anywhere, but thoughtful suggestions will.
6. Even though you aren't proficient with OpenACS (yet), you may have other skills that are useful. For example, some people have UI design skills, others may have Linux administration skills, or a security background.

I write this not because you're going to have trouble getting help. On the contrary, I've seen people in the OpenACS community help out people that are being very demanding and troublesome. My main hope in writing this is to give newbies a guide to how to most effectively get information.

Documentation and help pages for individual .LRN installations

Created by Caroline Meeks, last modified by Olga C. Santos 02 Jul 2006, at 01:58 PM

Typically each .LRN installation writes up a set of end user documenation that is specific for thier site.  This allows them to use screenshots with thier skin and adjust for what packages and features that institution is using. It may also reflect the policies of that institution.  A number of institutions have shared thier manuals, help pages etc. so you can use them as examples for creating your own.  

 SloanSpace - sloanspace.mit.edu - dotLRN

• Overview - Wink video
  
• Tutorials in pdf format
  
• Users Handbook - html but paths images are broken, contact Caroline to volunteer to fix them
• Users Hanbooks in pdf format
• Survey - Wink Video
  
• WebDav instructions in html but paths images are broken, contact Caroline to volunteer to fix them
• WebDav Wink Video
  
• Export Calendar to Outlook - Wink video
• Registration - Wink Video
  

Pathways To China Instructors Manual - pathwaystochina.org - dotLRN and dotFolio for a high school level program.

Solution Grove Client Documentation - Documentation for various client sites that use dotLRN, dotFOLIO and OpenACS

name with space

Created by Gustaf Neumann, last modified by Gustaf Neumann 20 Jun 2006, at 10:43 AM

XCMS User Interface

Created by Robert Taylor, last modified by Torben Brosten 01 May 2006, at 11:02 AM

Package Specification Summary for Package: xcms-ui

Bug Tracker Summary for Package: xcms-ui

There is no package with the name "xcms-ui" known to bug-tracker.

Code Metrics Summary for Package: xcms-ui