/ 
OurNet-BBS-1.67
River stage one • 1 direct dependent • 1 total dependent
/ OurNet::BBS::Roadmap

NAME

OurNet::BBS::Roadmap - The OurNet-BBS development roadmap

SYNOPSIS

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 heterogeneous 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 on-line services.

While not an end in itself, OurNet-BBS MUST provide a clearly defined layer for writing inter-operable agent and services in a server-less 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 similar 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 / ColaBBS

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.

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 behavior. 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 serve 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.

External

The External backend SHOULD launch external programs for each STORE or FETCH actions performed on its components; it is used to e.g. gateway all STORE attempts to a mailer, as a BBS <=> Mailing list gateway.

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, PostgreSQL, MS SQL and Oracle DBDs. It MUST provide a reference schema of necessary fields for each components, and SHOULD accept other schemata 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 behavior.

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 necessary for sites using existing systems to convert to MELIX, in order to fully utilize the OurNet-BBS platform.

Such migration kits MUST preserve static data as much as possible, and SHOULD retain the same structure and content in the OurNet perspective.

Service Transports

The service transports allows interoperability between OurNet-BBS objects and other distributed systems.

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

OurNet-BBS SHOULD layer itself on top of a distributed computing network that allows Server-to-Server communications.

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 necessary 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 heterogeneous 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

The documentation set of OurNet-BBS is distributed under the OurNet::BBS::* namespace.

Architecture and Philosophy
Interface and Samples
Test Cases With Comments
Backend Developer's Guide
Agent Developer's Guide

MILESTONES

Milestone 0

This milestone gives the baseline of basic functionalities, and a working prototype of RPC + Access Control network. It also includes man pages and overviews.

backend:	MAPLE2, PTT, MAPLE3, MELIX.
wrapper:	RAM, BBSAgent, NNTP, MailBox.
transport:	OurNet-RPC.
agent:	Telnet Agents, Access Control (MELIX).

Milestone 1

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

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

Cross-node messaging, presence and session management are the main purpose for 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

This milestone turns existing OurNet network into a true Agent Platform, by offering intention- and subscription- based syndication between nodes.

rendering:	Web Framework Integration.
network:	Syndication.
agent:	Transportable Objects.
document:	Agent Developer's Guide.

AUTHORS

Autrijus Tang <autrijus@autrijus.org>

COPYRIGHT

Copyright 2001-2002 by Autrijus Tang <autrijus@autrijus.org>.

This document is open document; you can redistribute it and/or modify it under the Open Content License.

See http://opencontent.org/opl.shtml