Bill's Index

RCCS Design Notes Index

Updated: 13Dec2003:

Introduction

RCCS contains my design notes for a Real Community Conferencing System. It is based on my 16 years of experience as a BIX moderator and Exchange Editor. This period covers the startup, growth, time of troubles and final closing.

My goal in a new design for BIX software was to save what was good about BIX, and replace/fix what was not. That is why you will find management and control issues in the design, because that's where BIX was weakest.

One of the main objectives of the design was to remove the limitation of a single central site for RCCS. Community conferencing should be a community affair, not just one location in complete charge of every operation.

Design Concepts

RCCS design is intended to be expandable dynamically to multiple cooperating sites. I have not yet spelled how this is to be done in detail, but the design allows for the exchange of updates with one site as the coordinator to keep sequence and threading synchronized.

In particular, I would expect that different sites would specialize in different subjects and areas of interest, yet allow those to be shared. Optionally, each site could determine for its own subjects whether to allow comments from other cooperating sites, and which ones. Thus control and cross domain exchanges would tend to eliminate rouge site input and yet provide a safety valve against excessive control.

While the design has been criticized for its hardware oriented selection of sizes and numbers, it was done carefully so as to not significantly limit the actual use. The specific reason for this design technique was to make a high performance design that works efficiently at all levels and therefore does not require large SMP systems to support a large group of users simultaneously. In fact, the design enables the use of cluster technology as a site grows, because the synchronization is built into the design.

Work To Be Done

As time permits, I will revisit these design notes and revise them for more detail, particularly in the areas of distributed sites, cooperation and control. As each section is updated, I will post an update notice in the Journal and this index. Reader feedback is welcome - send your comments to bwrite $at$ ywave.com.


RCCS Original Design 03Oct2000

In honor of the real community of people I met on BIX, I named this new design the Real Community Conferencing System (RCCS). The software under BIX was written at the University of Guelph in Canada, by a soft spoken genius named Alastair Meyer. It has since been revised and released as open source.

The design discussed here is different because it is based on a multi site, multi owner concept for shared and exclusive subject areas. But without BIX and my experience on BIX, this document would not exist.

Design Notes on RCCS Structure

Note: The specific size limits for the structure are not required, they simply reflect my initial implementation concept. What is important is the separation of data and management areas for flexability, and the six levels of RCCS data.

RCCS Conference Definitions

The conference structure has certain definitions that need to be followed to enable sharing across areas and across systems globally. Without these definitions, people will create structures that would require replicating at different levels of the conference for the same discussion.

Administration and Privilege Design

The purpose of this section is to provide flexible management control over a conferencing system while allowing a lot of freedom to experiment and some capability for the users to exercise choice and control over actions which are offensive to the majority.

Physical Design Notes

These notes were an initial design for very compact structure while allowing for very large systems. The fixed limits are not necessary, they were designed to fit into 16 and 32 bit word structures. This is easily changed.

Authority Structure

This sections specifies, albeit briefly, what authority goes with which level of person in the administrative area. Please note the assumption that the administration data is kept separately from the conference data. The problem is one of too tight coupling.

Message and Index Design Notes

Again, as part of the design for compact structures, the individual components were designed to fit efficiently into 32 bit words and 512 byte blocks. Messages were blocked rather than variable length for faster access and faster rebuilding if needed.

All content on this site is Copyright 2001 and 2002 by Bill Nicholls