NAME
OurNet::BBS - Component Object Model for BBS systems
SYNOPSIS
use strict;
use OurNet::BBS;
my $backend = 'MELIX'; # use the Melix BBS backend
my $bbsroot = '/home/melix';
my $board = 'sysop';
my $BBS = OurNet::BBS->new($backend, $bbsroot);
my $brd = $BBS->{boards}{$board};
my $mtime;
printf (
"This BBS has %d boards, %d groups.\n",
scalar keys(%{$BBS->{boards}}),
scalar keys(%{$BBS->{groups}}),
);
eval { $mtime = $brd->{articles}->mtime };
die "Error: cannot read board $board -- $@\n" if $@;
printf (
"The $board board has %d articles, %d toplevel archive entries.\n",
$#{$brd->{articles}}, $#{$brd->{archives}},
);
# A simple Sysop board article monitor
print "Watching for new articles...\n";
while (1) {
print "=== wait here ($mtime) ===\n";
sleep 5 until ($brd->{articles}->refresh);
foreach my $article (@{$brd->{articles}}) {
print "Found article: $article->{title}\n"
if $article->btime > $mtime;
}
$mtime = $brd->{articles}->mtime;
}
DESCRIPTION
OurNet-BBS is a cross-protocol distributed network, built as an abstraction layer over telnet BBS-based systems used in Hong Kong, China and Taiwan. It implements a flexible object model for different BBS backends, along with an asymmetric authentication and remote procedure call protocol.
This project aims to become a protocol agnostic middle ware solution for identity-based information storage & retrieval, much like the Project Jabber's goal toward instant messaging, or Project JXTA's aim toward distributed services.
For some of its practical uses, search for OurNet::BBSApp on CPAN.
DESIGN GOALS
There are several design goals for the OurNet-BBS:
Secure Communication & Storage
The most fundamental weakness of thin-client architectures is the vulnerability of tampering, either by intercepting transmissions or preying on unencrypted data stored on the centralized server. Therefore, OurNet-BBS MUST provide means to retrieve, forward and store data securely.
Multiple Representation Paradigms
In order to translate between heterogenous services within a common network, OurNet-BBS MUST accept both storage-based (eg. HTTP/FreeNet/LDAP) and message-based (eg. Jabber/XML-RPC) renderings, and be able to render into corresponding formats (eg. HTML/XML/MIME).
Decentralized Syndication Support
Monolithic, single point-of-failure servers has remained as the state of art in telnet-based BBS networks since the very beginning, which leads to its incapability to leverage viewers, services and computing resources on client machines as well as the high failure rate in online services.
While not an end in itself, OurNet-BBS MUST provide a clearly defined layer for writing interoperable agent and services in a serverless environment, either by utilizing existing networks (eg. Gnutella, JXTA, FreeNet) or by creating its own network.
COMPONENTS
Since OurNet-BBS is a large undertaking, its various components are relatively independent with each other, and are better viewed as sub-projects working collaboratively.
BBS Backends
OurNet-BBS MUST provide backends for all major telnet-based BBS systems, akin to DBD::* database access drivers.
These backends SHOULD support all existing services available through telnet-based interfaces, including boards, articles, nested archives, board classes, user info, mailbox, sessions, instant message, and chat rooms.
Backend developers are strongly encouraged to actively abstract similiar file-based operations among components, via the OurNet::BBS::Base object framework.
All backends MUST provide the same interface for Board, Article and User components, and SHOULD support Group and Session wherever applicable.
- MAPLE2 / SOB / PTT / ProBBS (a.k.a. CVIC)
-
Instead of supporting the common subset of all M2 variants, OurNet-BBS SHOULD provide a complete coverage to their unique feature and formats, and inherit as many common components from MAPLE2 as possible.
- MAPLE3 / MELIX
-
Because of the uncoordinated and heavily forked status of GPL'ed MAPLE3 code, OurNet-BBS MAY choose to ignore unpolished features (eg. Board Class), and to target MELIX's implementation instead.
MELIX's handling of MIME header and scripting language support SHOULD be utilized as the reference implementation, until another system appears with superior capabilities.
- FireBird2 / FireBird3
-
In addition to offering transparent access between Maple and FireBird series, OurNet-BBS MAY implement FireBird-specific features available through its telnet interface, if possible.
- ColaBBS / RexchenBBS / TwolightBBS / ...
-
Newer BBS systems unrelated to the Eagles-Phoenix ancestry also MAY be supported, if under substantial usage and/or offers advanced features as OurNet-BBS' representation layer.
Wrapper Backends
These backends SHOULD map their native data representation into traditional ones, and MAY offer additional options to control their behaviour. They SHOULD NOT break any semantics common to all traditional backends.
- RAM
-
This is the skeleton implementation which MUST support common subsets of all possible components, and serves as a reference for resolving conflicts between backends. It also MUST NOT rely on any on-disk storage or operating system dependent features.
- BBSAgent
-
Because most existing BBS sites will not offer OurNet-BBS service overnight, a translation layer over their telnet interfaces MUST be supported.
This backend SHOULD implement FETCH interfaces of Article, Board, User and Session components, and MAY provide STORE interfaces to them.
See "Agent Platform" for a discussion on telnet-based agent scripting interfaces.
- NNTP
-
For transparent synchronization with Usenet nodes, this backend MUST implement a RFC977-compliant client, and SHOULD transmit MIME data without loss.
This backend MUST supported Article and Board components, and MAY provide a Group component.
- POP3 / MailBox / IMAP / SMTP
-
These backends MUST support read/write operations with consistency, and SHOULD transmit MIME data without loss.
Two or more protocols MAY be combined to provide a read/write interface.
- DBI
-
This backend MUST support MySQL, PosgreSQL, MS SQL and Oracle DBDs. It MUST provide a reference schema of neccessary fields for each components, and SHOULD accept other schemas using clear-defined configuration methods.
Content Rendering
Some representation layers, such as stateless HTTP, does not allow a transparent integration. Nevertheless, OurNet-BBS SHOULD provide rendering tools to perform batch import / export against different targets.
- WebBBS Plug-in
-
This CGI-based interface MUST be capable of handling user sessions, authentication and have customizable templates. It also SHOULD NOT depend on any specific backend's behaviour.
- Web Framework Integration
-
In addition to stand-alone dynamic rendering, OurNet-BBS also MAY offer integration support to major web frameworks (eg. Slash, Zope, etc). Such integrations SHOULD render OurNet objects into HTML format without loss, and vice versa.
- Cross-Backend Migration Kit
-
Since not every backends support all OurNet-BBS components, it is sometimes neccessary for sites using existing systems to convert to MELIX, in order to fully utilize the OurNet-BBS platform.
Such migration kits MUST perserve static data as much as possible, and SHOULD retain the same structure and content in the OurNet perspective.
Service Transports
XXX: To be determined
- OurNet-RPC / XML-RPC
- Jabber
- CORBA / SOAP / EJB / LDAP / etc
-
OurNet-BBS MAY also offer additional bindings to these protocols, provided that there are corresponding needs.
Decentralized Networking
XXX: To be determined
- Discovery
- Messaging
- Authentication
- Syndication
Agent Platform
The medium-term goal for OurNet-BBS is to become a backend-independent Agent platform, consisting of all interconnected OurNet nodes. It is therefore neccessary to offer a common set of API and infrastructure to encourage people writing OurNet Agents.
- Telnet Agents
-
Besides static storage handled by backends, many Internet services needs to interact with OurNet (eg. BBS, IRC and Telnet) lacks a cleanly-defined API layer. Thus, a generic wrapper module is needed.
This module MUST provide an object-oriented interface to those services, by simulating as a virtual user with action defined by a script language. This language MUST support both flow-control and event-driven interfaces.
- Access Control
-
This module MUST support both traditional
crypt()
-based and asymmetric authentications. It also SHOULD negotiate among multiple available ciphers. The permission model MUST allow user-defined fine grained control, including ACL, OPCode locking, and respects the default settings of each backends. - Transportable Objects
-
This module MUST allow ircbot-like agents to deserialize and walk through nodes, to translating requests across heterogenous services. It also MUST allow each signed objects to be distributed and discovered across OurNet, so each node could look at the source code, run it in a Safe compartment, and if they like it, they could sign it to vouch for its integrity.
Documentation
XXX: To be determined
- Architecture and Philosophy
- Interface and Samples
- Test Cases With Comments
- Backend Developer's Guide
- Agent Developer's Guide
MILESTONES
Milestone 0 - v1.6 - 2001/09/01
This milestone gives the baseline of basic functionalities, and a working prototype of RPC + Access Control network. It also includes manpages and overviews.
backend: MAPLE2, PTT, MAPLE3, MELIX.
wrapper: RAM, BBSAgent, NNTP, MailBox.
transport: OurNet-RPC.
agent: Telnet Agents, Access Control (MELIX).
Milestone 1 - v1.7 - 2001/10/15
This milestone aims to provide a working public beta based on old client/server model. It will focus on core stability, a complete test case, and introductory materials.
agent: Access Control (MAPLE2).
rendering: Migration Toolkit.
document: Architecture & Philosophy,
Interfaces & Samples,
Test Cases With Comments.
Milestone 2 - v1.8 - 2001/12/01
This milestone is for co-operability toward developers. It will have a fully-functional reference implementation of Web rendering, as well as a procedural interface suitable to bindings with other languages. An experimental discovery network should be formed by this milestone.
wrapper: POP3/SMTP.
transport: XML-RPC.
rendering: WebBBS Plug-in.
network: Discovery.
document: Backend Developer's Guide.
Milestone 3 - v1.9 - 2001/01/15
Cross-node messaging, presence and session management are the main purpose fors this milestone. By this release, we should also gradually move away from depending on text-file based storage.
transport: Jabber.
wrapper: DBI.
network: Messaging, Authentication.
Milestone 4 - v2.0 - 2002/03/01
This milestone turns existing OurNet network into a true Agent Platform, by offering intention- and subscription- based sydication between nodes.
rendering: Web Framework Integration.
network: Syndication.
agent: Transportable Objects.
document: Agent Developer's Guide.
HISTORY
- v1.62, Mon Oct 15 07:48:58 CST 2001
-
No longer depends on GnuPG::Interface to run.
The OurNet protocol has been updated to
0.4
with callback support.Assigning a coderef directly (but not inside refs) via OurNet now works.
New, write-only External backend to utilize sendmail and the like.
Tainting check should now work on bbsboard and bbsmail.
GC stability on perl v5.6.x is much better.
A revised, more flexible Makefile.PL.
- v1.61, Fri Sep 28 00:53:46 CST 2001
-
Adds a read-only, experimental Cola backend.
Implements re-authentication for Server.
Bundles bbsboard and bbsmail utilities.
The BBSAgent backend now has a logfile property for debugging use.
Permission model and group support for CVIC.
Fixes various Base namespace pollution bugs.
Public key-based login is working now.
Additional Server options could be set in
%OurNet::BBS::Server::Options
.Introduced the Bundle::OurNet namespace.
- v1.6, Mon Sep 3 23:07:36 CST 2001
-
Changed Server and Client's default port from 7978 to 7979.
Complete ArticleGroup permission model for MELIX.
A <-g> options now enables bbscomd to accept guest-privileged connections.
Delete board / articles now works in file-based backends.
Changed DBI to RAM; it has nothing to do with DBI anyway.
Integrated the new set of design documents into manpage.
- v1.6-delta, Mon Aug 28 01:47:18 CST 2001
-
Session support for MELIX backend.
Purged LWP support from tree; nobody's using it anyway.
Fixed context problems of NNTP and OurNet backends.
The OurNet protocol could now pass back arguments by reference.
Passes tests on Win32 now.
Post-back of BBSAgent and SessionGroup fixed.
- v1.6-gamma, Thu Aug 16 17:37:12 CST 2001
-
The test cases in
t/
are now numbered, and OurNet-based tests added. For the first time, all tests pass.Implemented
{'owner'}
fetch for CVIC groups.The chrono-ahead algorithm now works correctly for all backends, so there will no longer be duplicate
Message-ID
s.Fixed the MAPLE3 backend's incestous relationship with MELIX.
Upgraded the Authen protocol to v0.3. Setting the flag
$OurNet::BBS::BYPASS_NEGOTIATION
now bypasses handshaking altogether. - v1.6-beta, Tue Aug 14 03:31:10 CST 2001
-
A streamlined
t/stdtest
base now applies to all three file-based backends.The
{''} = ...
STORE-as-PUSH semantics is fully supported.Group metadata unified into hash-based
{owner|title|id}
.Compatibility for perl 5.7.x, including line disciplines.
The long-timed 'extra test' heisenbug has been eliminated.
- v1.6-alpha, Sun Aug 12 19:03:08 CST 2001
-
Added the HISTORY secion in manpage.
Rewritten Base to be
overload
-based.Eliminated ArrayProxy and pseudohashes.
Uses Test::More instead of Test.
Improved MIME and mail address parsing regexes.
A much faster and robust NNTP backend.
The DBI backend rewritten to indicate style change.
- v1.56, Mon Jul 23 02:12:06 2001
-
File access via FileGroup components.
Group support for MAPLE3 with a twisted API.
Proper permission control for nearly all componetts.
Unix-style mailbox support via the MailBox backend.
CR/LF bug on Win32 eliminated.
- v1.55, Wed Jun 20 06:17:16 2001
-
The full OurNet authentication model.
Fixed UserGroup for MAPLE* backends.
A new Message-ID formula.
Fixed core dump in various, but not all, places.
Massive speed increase.
- v1.54, Wed Jun 13 11:43:12 2001
-
This version implements the new OurNet (formerly known as PlClient) asymmetric-key based authentication model, article/board permission model for M3 backends, numerous bugfixes, win32 support, and much, much more.
- v1.53, Sat Jun 9 11:09:26 2001
-
Full bbscomd support; PlClient is now a valid backend. (autrijus)
Finally fixed the internal object model; using multiple backends was broken due to back-propagation of initvar() variables. (autrijus)
STORE into MAPLE* backends should now update shm correctly. (autrijus)
Improved BBSAgent error handling for fail-safe operations. (clkao)
Fixed hazard caused by remote empty (or deleted) articles. (clkao)
Nickname support for MAPLE2/CVIC is reimplemented. (clkao)
BBSAgent now matches nickname even in pathetic cases. (smartboy)
- v1.52, Wed Jun 6 05:53:54 2001
-
Clean-up release to fix many 1.51 glitches, with added documentation and test cases added.
- v1.51, Sat Jun 2 07:05:18 2001
-
Forked out from
libOurNet
distribution.Vastly improved support for BBSAgent backend to support ebx, with many parsing enhancement and templates from smartboy.
- v1.4-alpha4, Fri Mar 23 03:21:14 2001
-
Integrated the MAPLE3 backend.
- v1.4-alpha3, Fri Jan 12 04:57:17 2001
-
First Win32 (ppm) release.
- v1.4-alpha2, Mon Jan 15 07:39:00 2001
-
Adds LWP::Protocol support and Session components.
- v1.4-alpha, Fri Jan 12 04:54:29 2001
-
First CPAN release, featuring the BBSAgent backend.
- v1.3, Fri Dec 29 05:40:11 2000
-
Provides simple remote access via OurNet::BBS::PlClient.
- v1.2, Thu Dec 7 05:02:39 2000
-
Backend abstraction revised; added PTT backend by gugod.
- v1.1, Tue Nov 21 19:00:33 2000
-
Initial commit, with CVIC as the only backend.
AUTHORS
Chia-Liang Kao <clkao@clkao.org>, Autrijus Tang <autrijus@autrijus.org>
COPYRIGHT
Copyright 2001 by Chia-Liang Kao <clkao@clkao.org>, Autrijus Tang <autrijus@autrijus.org>.
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.