Index: openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/configuration.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/configuration.xml,v
diff -u
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/configuration.xml 29 Jun 2001 20:35:39 -0000 1.1
@@ -0,0 +1,116 @@
+
+Advanced Configuration
+
+
+The ACS 4.0 permissions system is about hierarchies and in particular
+hiearchical containment. There are three important hiearchies:
+
+
+
+
+the user hierarchy (users, groups, and parties)
+
+
+
+the object hierarchy (objects nested in the contexts of others)
+
+
+
+the privilege hiearchy (privileges can entail other entails).
+
+
+
+
+This complexity of mechanism is designed to allow for
+simplicity of use for programmers and administrators. Unfortunately,
+interfaces to facilitate this simplicity of use are not here yet. Until then,
+sophisticated control and configuration of BBoard necessitates an
+understanding of these details.
+
+
+The first hierarchy is straightforward. There are users and groups (or
+together parties). Privileges granted to groups inherit to their members.
+
+Unless explicitly disabled (see below), privileges granted to parties are
+inherited down an object hierarchy. The nature of the BBoard hierarchy is as
+follows: subsites contain bboard package instances; bboard package instances
+contain forums; forums contain both categories and messages. Privileges
+granted to parties on the package instance are inherited to all the forums
+nested within and so on.
+
+The third hiearchy is the least clear. Privileges can be nested into other
+privileges. This lets us group related privileges like those for reading a
+message and reading a forum together to allow us to easily grant "read
+access" on a hiearchy of objects to a party even though there are
+separate notions of "read a message" and "read a forum".
+All the bboard privileges are nested in one of the following system level
+"super"-privileges: "read", "write",
+"create", "delete", and "admin".
+
+The full set of self explanatory bboard privileges is listed here:
+
+
+bboard_create_forum
+bboard_create_category
+bboard_create_message
+bboard_write_forum
+bboard_write_category
+bboard_write_message
+bboard_read_forum
+bboard_read_category
+bboard_read_message
+bboard_delete_forum
+bboard_delete_category
+bboard_delete_message
+bboard_moderate_forum
+
+
+
+
+Permissions on package instances are controlled through the "set
+permissions" options on the appropriate folder in the admin site map
+(/admin/site-map/). While in principal, the system should allow you to grant
+permissions on lower level objects like forums or even individual messages
+and categories, right now the UI is limited to granting permissions on the
+application instance. SQL*Plus users or even URL hackers can probably figure
+out how to do this if they're so inclined.
+
+
+The default set of permissions granted in a bboard system are those
+inherited from the main site:
+
+
+Registered Users have bboard_create_message
+
+The Public has bboard_read_category
+
+The Public has bboard_read_forum
+
+The Public has bboard_read_message
+
+The Public has read
+
+[Admin user] admin
+
+
+
+Granting additional privileges to parties is fairly straightforward. For
+moderated forums, creating a moderators group and granting them
+"bboard_moderate_forum" (or "admin" if you're feeling
+lucky) will let you delegate more of the discussion culling.
+
+
+For significantly different configurations you might need to revoke
+privileges already granted by the defaults. In this case you must configure
+the package instance not to inherit permissions from the main site and then
+add back any permissions needed. Granting "read" to registered
+users and bboard_create_message to "Elite d00ds" will give you a
+pseudo-private forum.
+
+Note: To facilitate usability in the common case, BBoard pages present the
+option to post or reply even if the user doesn't have the
+bboard_create_message privilege. If you remove posting ability from
+registered users, you may wish to alter the templates to appropriately
+display options.
+
+
\ No newline at end of file
Index: openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/design.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/design.xml,v
diff -u
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/design.xml 29 Jun 2001 20:35:39 -0000 1.1
@@ -0,0 +1,352 @@
+
+ACS Messaging & BBoard Design Document
+
+
+
+Essentials
+
+
+
+User directory: /bboard/
+
+
+
+Data model: bboard-create.sql
+
+
+acs-messaging-create.sql
+
+Data-model diagram
+
+
+
+
+
+Introduction
+
+
+bboard is an ACS application package built to provide
+scalable discussion forums to a community of users. As in older versions,
+bboard provides:
+
+
+posting, browsing, and reading of messages in discussion forums
+
+tools for moderators to maintain editorial standards
+
+categorization and retrieval for knowledge management
+
+
+
+The initial 4.0 implementation adds the following new features:
+
+
+
+fully templated presentation layer for easy customization
+
+improved access control on bboard operations to support a wide variety of
+publisher policies
+
+support for multiple distinct configurations of the bboard package (e.g.
+different forums and options at http://foo.com/bboard/ and
+http://foo.com/pittsburgh/bboard/)
+
+
+
+
+
+
+The ACS 4.0 version of bboard is a re-engineering of the data
+model and presentation layer without certain capabilities present in the ACS
+3.4 bboard. In future releases we intend to achieve the same level of
+maturity as the older bboard while building on the flexibility
+of the new design.
+
+
+In particular this implementation (9/2000) does not include the following
+features found in prior versions:
+
+
+
+support for expiring messages
+
+facilities for spamming dynamic classes of bboard users
+
+bboard messages with rich media attachments
+
+email alert functionality
+
+full text messages searching
+
+
+bboard is not intended to be the ultimate
+customizable web based discussion system. It is intended to be a practical
+and useful system that supports forums much like the photo.net Q&A forum.
+Publishers with special needs are encouraged to implement their solution as a
+module, much like bboard, built atop the framework acs-messaging
+provides.
+
+acs-messaging is a general purpose component that provides
+threaded messaging services to higher level applications such as
+bboard. The motivation is to provide a base level data model and
+reusable presentation code that enables the rapid customization of messaging
+applications. acs-messaging is intended to simplify modules like
+general comments and webmail, as well as
+specialized messaging applications such as scorecard's geospatial bboard. Such
+a framework keeps custom organizational metadata, pageflow and navigation,
+and publishing and moderation policy separate from the basic tools needed for
+discussion.
+
+
+
+
+Historical Considerations
+
+
+Over the course of ACS development, bboard has grown to
+encompass a wide variety of functionality. Much of this functionality was
+developed first for bboard and only later adapted into more
+general mechanisms (e.g. alerts, security, group scoping, etc.,). However
+bboard wasn't refactored to take advantage of the more
+general facilities, and its complexity challenged those in need of custom
+features. Furthermore there was a lot of ad hoc mechanism in both the data
+model and page flow to support different presentation styles, navigation
+schemes, and access control models. Although this bboard proved
+to be useful, scalable, and reliable, the ability to maintain and extend this
+code suffered.
+
+
+
+The ACS 4.0 release of bboard mimics the basic functionality of older
+bboard versions but built atop new ACS 4.0 general mechanisms
+(objects, persmissions, templating, acs-messaging, etc.,).
+
+
+
+
+
+Competitive Analysis
+
+
+An analysis of the bboard feature space should be added here.
+
+
+
+USENET a la gnus
+
+slashdot
+
+Userland
+
+????
+
+
+
+
+
+Design Tradeoffs
+
+
+How does one reconcile all the possible discussion forums mentioned above
+into a single module? One does not! bboard is precisely one way
+to implement a discussion forum and should not be all things. In time, there
+should be a toolkit of components (user interface, data model, and
+procedural) for developers to assemble their custom.
+
+Although many of the entities in the data model are implemented as
+subtyples of ACS object, we avoid using information from the ACS object table
+for anything but auditing purposes. For example, we could store a
+message's author in the ACS object creation_user field, however to keep
+query performance in line we rather use the author field in acs_messages.
+
+
+
+
+API
+
+
+As of the initial ACS 4.0 release, acs-messaging and
+bboard do not provide well defined programming interfaces.
+
+Although convenience functions will be provided for basic transactions on
+the acs-messaging and bboard entities, it remains
+to be seen what sort of abstraction layer is most appropriate.
+
+
+
+
+Data Model Discussion
+
+
+acs-messaging defines the view acs_messages_all
+for the storage and access of threaded text messages and assorted information
+relevant to their display, access, and creation. Under the covers
+acs-messaging use the content repository for underlying
+storage.
+
+bboard uses acs-messaging messages, and
+organizes them into forums and categories. For the purposed of the ACS
+permissions system, forums contain messages, and so any permissions on a
+forum will default to being inherited for individual messages.
+
+A forum may be designated as moderated, in which case explicit approvals
+or denials are stored in the bboard_message_moderation. Messages
+without entries in the moderation table are considered unseen, and will be
+displayed or hidden in moderated forums based on policy.
+
+Each forum may have some number of categories, tags denoting further
+specialization within a forum. Messages of a forum may be tagged as being in
+any of the categories pertaining to that forum.
+
+Permissions
+
+
+Permissions in ACS 4.0 involve 3 interrelated hierarchies: users &
+groups, objects, and privileges. The user and group hiearchy is generally
+explained elsewhere. The short explanation:
+
+
+The long explanation: BBoard defines the following permissions:
+
+
+nested under the create permission:
+
+bboard_create_forum
+
+bboard_create_category
+
+bboard_create_message
+
+nested under the write permission:
+
+bboard_write_forum
+
+bboard_write_category
+
+bboard_write_message
+
+nested under the read permission:
+
+bboard_read_forum
+
+bboard_read_category
+
+bboard_read_message
+
+nested under the delete permission:
+
+bboard_delete_forum
+
+bboard_delete_category
+
+bboard_delete_message
+
+nested under the moderate permission:
+
+bboard_moderate_forum
+
+
+
+
+
+User Interface
+
+...
+
+
+
+
+Configuration/Parameters
+
+...
+
+
+
+
+Acceptance Tests
+
+...
+
+
+
+
+Future Improvements/Areas of Likely Change
+
+
+Much of the functionality of the ACS content repository will eventually
+provide tangible benefits to bboard and any
+acs-messaging application. Foremost among these features will be
+full text searching and rich media attachments.
+
+When ACS provides a general mechanism for an installation to send and
+receive email, bboard can provide email alerts and email based
+reply and post.
+
+
+
+
+Authors
+
+
+Anukul Kapoor
+
+
+
+
+
+Revision History
+
+
+
+
+
+Document Revision #
+Action Taken, Notes
+When?
+By Whom?
+
+
+
+
+
+
+0.2
+Revision
+09/19/2000
+Anukul Kapoor
+
+
+
+
+0.1
+Creation
+09/01/2000
+Anukul Kapoor
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Index: openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/index.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/index.xml,v
diff -u
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/index.xml 29 Jun 2001 20:35:39 -0000 1.1
@@ -0,0 +1,66 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+]>
+
+
+Bboard Documentation
+
+
+
+ For Everyone
+
+
+ Overview
+ Brief introduction, support possibilities and release notes
+
+
+ &introduction;
+ &support;
+
+
+
+
+
+ For Admins
+
+
+ Overview
+ Installation, maintenance
+
+
+ &installation;
+ &configuration;
+
+
+
+
+ For Developers
+
+
+ Overview
+ Requirements, design
+
+
+ &requirements;
+ &design;
+
+
+
+
Index: openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/installation.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/installation.xml,v
diff -u
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/installation.xml 29 Jun 2001 20:35:39 -0000 1.1
@@ -0,0 +1,185 @@
+
+Installation and Configuration of Bboard
+
+
+Installation
+
+
+Using bboard requires an operating ACS 4.0.1 installation. If you haven't
+upgraded, do so first.
+
+
+
+Installing and enabling the bboard package should be
+relatively painless, just:
+
+
+
+
+go to your server's
+/acs-admin/apm/package-load
+page, enter
+"www.arsdigita.com/acs-repository/download/apm/bboard-4.0.2.apm"
+in the first text box
+
+
+
+
+
+click the button and follow the instructions
+
+
+
+
+
+If you're reading this on your own server, you've
+probably already done this.
+
+
+
+Once the package is installed and enabled, a subsite administrator can
+mount instances on their subsite. If you're the
+lone über-admin
+of your site, you can just go to your site's
+/admin/site-map/ page and:
+
+
+
+
+
+create a new subfolder under the "/" directory
+
+
+
+Pick a creative
+label for your subfolder like "bboard" or "dgroup"
+
+
+
+Select
+"new application" for that subfolder, and choose BBoard from the
+pulldown menu.
+
+
+
+
+It is probably best to label the application instance the same
+as your subfolder; do otherwise if it helps you keep your site straight.
+
+At this point you should have a BBoard instance mounted in the subfolder
+directory - for the rest of this document I assume that you've choosen "/bboard".
+
+
+
+
+
+Initial Configuration
+
+
+Before you can start using the Bboard you have to create some forums:
+
+
+
+
+log in as an administrator
+
+
+
+surf to /bboard and click "Create a forum"
+
+
+
+
+
+After you've created one or more forums you can specify the settings for your instance
+of Bboard from the Site Map
+(click set parameters).
+
+
+
+Most of the setting you see require a "t" (for true) or "f" (for false).
+The rest should be self-explanatory.
+
+
+
+
+ThreadingEnabledP
+
+
+
+This enables or disables threading indentation on a single thread basis.
+"t" enables threading and "f" (the default) turns it
+off.
+
+
+
+MailFriendEnabledP
+
+
+
+This enables the option for users to mail copies of a bboard posting to a
+friend (or themselves). Since this functionality can be abused, consider
+disabling the functionality.
+
+
+
+UserPostsEditableP
+
+
+
+This grants users privileges to edit their own message. Note: toggling
+this parameter will not change the ability of user to edit existing messages.
+This parameter only effects whether users are granted rights to edit at the
+message's posting time. This must be enabled for attachments to
+work.
+
+
+
+UserPostsDeletableP
+
+
+
+This grants users privileges to delete their own
+message. Note: This parameter only effects whether users are granted
+rights to edit their message's with the
+UserPostsEditableP.
+
+
+
+AttachmentsEnabledP
+
+
+
+This lets users who have edit capability on a message upload file or
+image attachments.
+
+
+
+
+MaxAttachmentSize
+
+
+This specifies the maximum size in bytes to accept for binary
+attachments. The default is 1 megabyte.
+
+
+
+
+DisplayLastNDays
+
+
+This parameter controls how many days worth of recent messages are
+displayed on the forum overview page by default. 0 specifies that all
+messages should be displayed.
+
+
+
+
+If you want to learn how to set more advanced parameters of your Bboard instance,
+read .
+
+
+
+
+
+
Index: openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/intro.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/intro.xml,v
diff -u
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/intro.xml 29 Jun 2001 20:35:39 -0000 1.1
@@ -0,0 +1,21 @@
+
+Bboard Introduction
+
+
+What is Bboard?
+
+
+BBoard is a web based discussion system for the ArsDigita Community
+System. Once installed and mounted, bboard instances provide
+locations on the site that contain discussion forums
+(e.g. http://developer.arsdigita.com/bboard/). Users can post and
+read messages within individual forums, which are generally geared
+towards specific topics or audiences. This basic functionality is
+supplemented with a variety of additional features including image and
+file message attachments, email notification, categorization, and
+moderation facilities.
+
+
+
+
+
\ No newline at end of file
Index: openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/notes.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/notes.xml,v
diff -u
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/notes.xml 29 Jun 2001 20:35:39 -0000 1.1
@@ -0,0 +1,42 @@
+
+Release Notes and Miscellaneous Stuff
+
+
+Release Notes
+
+
+This is the final release of BBoard 4.0.2. This release requires ACS
+Core 4.0.1, available from the ACS Repository.
+
+
+This version offers a working drop script, numerous bugfixes, and some
+notable improvements such as:
+
+
+support for binary attachments
+
+letting users email postings to others
+
+more informative displays
+
+performance improvements
+
+
+
+
+
+
+
+
+
+Miscellaneous Notes
+
+
+Text searching requires the maintaince of the content repository
+cr_rev_content_index index; either by hand or by context.
+
+
+
+
+
\ No newline at end of file
Index: openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/requirements.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/requirements.xml,v
diff -u
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/requirements.xml 29 Jun 2001 20:35:39 -0000 1.1
@@ -0,0 +1,427 @@
+
+Bulletin Board Requirements
+
+
+By Anukul Kapoor, Pete Su and Mark Thomas
+
+
+
+Introduction
+
+
+This document outlines necessary functionality and behavior of the new ACS
+4.0 Bulletin Board system (herein referred to as bboard).
+
+Our intent (as of 8/2000) is to start with a simple implementation that
+can accomodate future advanced functionality. As a result, these requirements
+may not prescribe functionality present in the ACS 3.4 bboard system. We are
+using the uslaw-bboard module as inspiration for a lightweight
+implementation.
+
+Futhermore, this document is conservative in attempting to describe the
+ultimate framework for modular web based messaging. We hope such an
+architecture may well be born out of iterative process when designing this
+system. However, the scope is being primarily limited to functional
+requirements.
+
+The future requirements should inform the design process if
+not initially implemented.
+
+
+
+
+Vision Statement
+
+
+An electronic bulletin board system is one of the simplest and most
+effective forms of collaboration between people separated in space and time.
+Bboards provide a centralized and shared venue for discussion that save
+communication costs over ad-hoc mechanisms (like arbitrary email lists).
+Since messages are organized by topic as well as temporally, bboard can
+provide lightweight interfaces for rapidly navigating to interesting
+messages. This low barrier to participation encourages spontaneous
+collaboration between disperse parties in the community.
+
+The bboard system also serves as a useful archive and ad-hoc knowledge
+management tool by virtue of its persistence, light weight organizational
+structure, and flexible browse and search facilities. This sort of knowledge
+base can be easily leveraged to provide long term pedagogical value as well
+as aid in future problem solving.
+
+When integrated with an email system, bboards radically improve email
+based collaboration. Email notifications can encourage continuous awareness
+of community issues. Email based reply functionality further lowers the
+barrier to participation, encouraging more Interaction around the
+Transaction™.
+
+
+
+
+System/Application Overview
+
+
+The bboard system allows users to browse, read, and post messages
+organized into forums. Messages consist of short text messages with optional
+attachments such as image files or html documents. Messages are organized
+into threads when users reply to each other, maintaining the temporal flow of
+a particular discussion.
+
+Forums are contexts for discussion relating to a particular domain of
+interest. Examples include the photo.net Q&A forum, the ArsDigita Web/DB
+forum, and the away.com discussion forum. Messages within a particular forum
+can optionally be tagged as being in certain categories to assist searching
+and navigation. Forums are always created in the context of a subsite.
+
+
+
+
+IV. Use-cases and User Scenarios
+
+
+Administrator: Phillis Goodsport is a world famous
+lithographer who wants to share her knowledge about lithography and encourage
+interaction between a community of lithographers on her new site litho.net.
+Although she likes the idea of a broad forum for general lithography
+discussion, she wants browsing to be tractable when traffic increases. If
+quality goes down, she'd like to dedicate one of her minions to
+moderating traffic to maintain her high standards.
+
+Casual browser and poster: Joe Schmoe goes to photo.net
+for the first time and wants to ask what zoom lens to buy. He needs to find
+the appropriate category/topic to post his message.
+
+Compulsive reader and expert poster: Jane Developer is a
+web development guru and wants to keep up with as much of the traffic on the
+web/db forum as possible. She wants to become aware of posts that might
+become relevant to her in the future as well as help out folks who have
+problems she knows how to solve. Since Jane is on lots of developer mailing
+lists, her preferred form of interaction is via email.
+
+Moderator: Dave Balderdash is a chatter.net moderator and
+wants to delete redundant or useless posts. He's short on time, so he
+wants a quick interface for rejecting and approving posts.
+
+Targeted researcher: Ted Stetson is an ACS developer who
+remembers someone mentioning something about his Oracle problem on a bboard.
+He wants to find records of similar problems and any related solutions.
+
+
+
+
+Related Links
+
+
+
+
+
+Test Plan (not available)
+
+
+notes on USLaw-BBoard implementation
+
+Subcommunities
+
+Karl's
+thoughts on bboard redesign
+
+Adam
+Farkas's web/db thread on bboard improvements
+
+
+
+
+
+Requirements: User Interface
+
+
+
+10.10 End User Basics
+
+
+10.10.10 The bboard system must provide mechanism for
+users to effectively choose which messages to read within a forum. Bboard
+must provide an overview interface to enable users to find messages of
+interest or relevant to them. This overview should provide the user with
+cursory information to facilitate quick scanning and meaningful evaluation of
+message contents.
+
+10.10.15 The full text of bboard messages should be
+searchable by user queries.
+
+10.10.20[unimplemented] Bboard
+should consistently provide a mechanism to limit or sort displayed posts by
+categories, posters, and date range as well as to perform a text search.
+
+10.10.30[unimplemented] Most
+users primarily want to browse and read new posts or replies since their last
+visit. The bboard interface must allow users to ignore messages they've
+already read.
+
+10.10.40[unimplemented] Users
+should be able to search within and limit scope to messages they have already
+read as well as messages they have not read at all.
+
+10.10.50 Users must be able to easily post new messages
+to a bboard, or reply to existing messages they have come across. When
+replying, users must be presenting with enough context to assist their
+composition.
+
+
+
+
+10.20 Email Integration
+
+
+10.20.10 Users can register for email notification of new
+messages in a particular forums.
+
+10.20.13 Users can register for email notifications on a
+particular thread.
+
+10.20.16 Users can register for email notifications on a
+particular category.
+
+10.20.20[unimplemented]
+Notifications can be sent as each message arrives or in an organized digest
+form over a configurable time period.
+
+10.20.30 Individual messages will have appropriate RFC
+822 headers to enable threading in the mail client.
+
+10.20.40[unimplemented] Email
+from the alert system should be tagged in the header with the site and forum
+name to enable easy filtering in mail clients. Well, as easy as the mail
+clients make it anyway.
+
+10.20.50[unimplemented] If the
+user requests it, email generated should use MIME encoding to deliver
+attachements and appropriately encode HTML. Otherwise plain text emails
+should be augmented with URLs and styling cues in place of rich content.
+
+
+
+
+10.30 Administrative Requirements
+
+
+10.30.10 The bboard system must support a flexible
+presentation layer that allows custom layout of bboard content.
+
+10.30.15 Publishers should have the option of displaying
+discussions in a flat linear fashion or in an indented threaded view.
+
+10.30.20 Parties with administrative privileges on a
+particular subsite can create, delete, and edit forums scoped to that
+subsite.
+
+10.30.30 Forums can be designated moderated in which case
+parties with sufficient privileges must approve messages before they are
+displayed generally.
+
+
+
+
+10.40 Access Control Requirements
+
+
+Objects must be structured to allow the flexible configuration and assignment
+of the following privileges:
+
+10.40.10 Reading forums
+
+10.40.20 Reading messages
+
+10.40.30 Posting new messages
+
+10.40.50 Approving and rejecting posted messages (for
+moderated groups)
+
+10.40.60 Managing the forum (editing title and
+description, determining moderation and restriction policies, granting
+approval privileges to others, banning users)
+
+10.40.70 Managing categories (editing, deleting,
+combining categories)
+
+20.10.10 Messages are the basic units of the bboard
+module. The bboard system will provide a repository to store text
+messages.
+
+20.10.20 Messages will be tagged as having HTML, plain
+text, or preformatted text in their body.
+
+20.10.30 Messages will have a brief plain text subject
+line.
+
+20.10.40 Messages will be related to their creating
+user.
+
+20.10.50 Messages may optionally have binary
+attachments.
+
+20.10.60 The bboard system must store relations between
+messages and their replies to enable threaded views.
+
+
+
+
+20.20 Forums
+
+
+20.20.10 Forums are the main administrative units of the
+bboard system. Forums are containers to which messages uniquely belong.
+
+20.20.20 Forums must have a brief text descriptions and
+optionally a longer description called a charter.
+
+
+
+
+20.30 Categories
+
+
+20.30.10 There must be a mechanism for intra-forum
+categorization to facilitate filter, searching, and tractability.
+
+
+
+
+
+
+Requirements: API
+
+
+No requirements in this section are met by the current
+implementation.
+
+Since bboard is primarily an end user application any exposed APIs will
+come out of the design rather than nailed down requirements from the start.
+Stay tuned.
+
+
+
+
+Possible Future Requirements
+
+
+
+40.10 In no particular order
+
+
+40.10.10 bboard should provide a framework for extending
+the generic messaging repository with meta-data and in tandem extending the
+user interface to take advantage of this meta-data. This would let developers
+properly layer functionality such as geo-spatial messaging and slashdot style
+scoring. This is actually provided via ACS messaging and the ACS Object
+system.
+
+40.10.20 bboard should support replying to and
+initiating threads from email. Administrative email list functionality should
+be developed or integrated.
+
+40.10.30 Bboard should let users register interests
+(categories, certain users, keywords) for the purpose of filtering and
+sorting message displays.
+
+40.10.40 Users should have the option of enabling spell
+checking on their posts. A framework for filtering (removing bad words,
+promoting text URLs to html links, auto detecting HTML vs. plain text, etc.,)
+should exist.
+
+40.10.50 Allow users to configure how big the textareas
+editing widgets they get are.
+
+40.10.60 Moderators should be given the option
+of making notes on a given discussion that appear prominently in the
+discussion display.
+
+40.10.70 Moderators should be able to set posts to
+expire at a configurable time in the future.
+
+40.10.80 Mega bonus points: an nntp gateway to bboards
+for access from standard news clients.
+
+40.10.90 The bboard system should be able to take
+advantage of a caching system that stores the results of database queries for
+optimal scalability.
+
+40.10.100 Publishers should have the option of allowing
+users to edit various parts of messages after they are posted (e.g. the text
+body, the subject, the text presentaiton style etc.,)
+
+40.10.110 A user interface should allow administrators
+to easily categorize or recategorize existing messages.
+
+40.10.120 Publishers should be able to classify users
+based on their forum contributions and appropriately target them for email,
+promotions, etc.,
+
+40.10.130 Explicit permissions for posting new messages
+vs. posting replies.
+
+40.10.140 Explicit permissions for posting
+attachments.
+
+
+
+
+40.20 Performance requirements
+
+
+
+
+
+
+Revision History
+
+
+
+
+
+
+
+
+Document Revision #
+Action Taken, Notes
+When?
+By Whom?
+
+
+
+
+
+0.2
+Revision: More standard style, more detailed requirements.
+08/24/2000
+Anukul Kapoor
+
+
+
+
+0.1
+Creation
+08/23/2000
+Anukul Kapoor
+
+
+
+
+
+
+
+
+
+
Index: openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/support.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/support.xml,v
diff -u
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/support.xml 29 Jun 2001 20:35:39 -0000 1.1
@@ -0,0 +1,57 @@
+
+Support
+
+
+There's a couple of different places you can turn to if this documentation
+comes short of answers to your questions or if you want to give us
+feedback:
+
+
+
+
+
+If you have a general question about usage of the application
+
+
+
+Ask on the
+applications bboard at arsdigita.com.
+
+
+
+
+
+If you want to report a bug or keep up-to-date on bug fixes
+
+
+
+Visit the
+ArsDigita SDM.
+
+
+
+
+
+If you are interested in the general status of the Bboard application
+
+
+
+Up to date info on BBoard is available from the BBoard status
+page.
+
+
+
+
+
+If you have questions, comments or suggestions to this documentation
+
+
+
+Visit the Documentation Central
+or fire directly at acs-docs@ardigita.com.
+
+
+
+
+
+
\ No newline at end of file
Index: openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/top.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/top.xml,v
diff -u
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ openacs-4/contrib/obsolete-packages/bboard/www/doc/xml/top.xml 29 Jun 2001 20:35:39 -0000 1.1
@@ -0,0 +1,66 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+]>
+
+
+Bboard Documentation
+
+
+
+ For Everyone
+
+
+ Overview
+ Brief introduction, support possibilities and release notes
+
+
+ &introduction;
+ &support;
+ ¬es;
+
+
+
+
+
+ For Admins
+
+
+ Overview
+ Installation, maintenance
+
+
+ &installation;
+ &configuration;
+
+
+
+
+ For Developers
+
+
+ Overview
+ Requirements, design
+
+
+ &requirements;
+ &design;
+
+
+
+