Files

Ken Johnson 892a4a559b Bootstrap fpc-bbs repo skeleton

A unified Free Pascal library for reading / writing BBS-side
file-area databases across multiple BBS systems.  Sibling to
fpc-msgbase and fpc-ftn-transport; same vendoring model.

Initial high-priority backend list (per consumer ask):
  - RemoteAccess (RA)
  - Maximus
  - Synchronet
  - Renegade 1.4

Secondary (Allfix already has type defs to lift from):
  - PCBoard
  - ProBoard

Skeleton only -- no concrete units yet.  Repo layout:
  README.md             family pitch + scope summary
  docs/scope.md         what's in / out, cooperative boundaries
  docs/architecture.md  layered design + cooperation diagram
                        with fpc-ftn-transport's tt.tic.* for the
                        full fileecho-toss flow
  build.sh              multi-target cross-compile harness
  run_tests.sh          x86_64-linux test runner
  fpc.cfg               default compiler config
  .gitignore            standard FPC artefacts

Next session: bbs.api (abstract TBbsBase) + bbs.types
(TFileArea / TFileEntry / etc.) so the first concrete adapter
has a target shape to fill in.

Reference for adapter ports: ~/Source Code/originalallfix/AllFix.1/
TPFILES/ALLFIX/ -- 92 .PAS files, ~56K lines.  PCBoard
(_PCBOARD.PAS + PCBTYPES.PAS), ProBoard (PROBOARD.PAS), TAG
(TAG.PAS), Synchronet (SYNCHNET.PAS), and the file-area
plumbing (FILECHO.PAS, FILEBONE.PAS, FAREA.PAS, DOSCAN.PAS) are
the primary lift sources.

TIC processing intentionally NOT in this repo -- TIC is a
wire / file-echo concern, lands in fpc-ftn-transport as
tt.tic.* modules.  Same logic that put PKT in fpc-ftn-transport
rather than fpc-msgbase.

2026-04-18 21:45:02 -07:00

4.2 KiB

Raw Permalink Blame History

fpc-bbs — scope

This document defines what fpc-bbs owns versus what lives in sibling libraries. Core principle: BBS-side storage of file areas, configs, and (eventually) user databases lives here. Wire / queue / TIC processing lives in fpc-ftn-transport. Message-base storage lives in fpc-msgbase.

In scope

File-area databases

Concern	Notes
FILES.BBS / DIR.LST per-area listings	BBS-specific format variants (PCBoard, ProBoard, RA, Maximus, Synchronet, Renegade 1.4)
File-area metadata	Area name / description / path / passwords / sysop / Magic / etc.
Add / remove / list file entries	Per-BBS write semantics (some are flat text, some are binary databases)
File flags	New-file marker, hatch source, sysop-only, free-download, etc.
Long descriptions	Multi-line file descriptions per FSC-0046 / vendor extensions

BBS configuration readers

Concern	Notes
Per-BBS main config	RA `CONFIG.RA`, Maximus `MAX.PRM`, Synchronet `.cnf`, PCBoard `PCBOARD.DAT`, ProBoard cfg, Renegade `.dat`
File-area config	Where FILES.BBS lives, area sec levels, conf number, etc.
Path resolution	BBS-relative path conventions, drive remapping (DOS heritage)

User databases (deferred)

Concern	Notes
`USERS.BBS` / `USER.DAT` reads	Lifted into a fpc-bbs sub-library only when an actual consumer needs it. Allfix doesn't, NetReader doesn't, Fimail doesn't. Adding speculatively is scope creep.

Out of scope (lives elsewhere)

Concern	Lives in
Message bases (Hudson / JAM / Squish / etc.)	`fpc-msgbase`
FTN transport (PKT / BSO / ArcMail / FilQueue / DBridge)	`fpc-ftn-transport`
TIC file format (FSC-0087)	`fpc-ftn-transport` (`tt.tic.format`)
TIC file processing (validate, toss, forward)	`fpc-ftn-transport` (`tt.tic.processor`)
BinkP session, EMSI, ZModem	`comet` / `nova`
Net mailer / outbound polling	`comet` / `nova`
BBS user authentication / dial-in	not our concern (each BBS owns its login flow)

Cooperative boundaries

with `fpc-ftn-transport`

A typical fileecho toss flow:

comet / mailer drops inbound .tic and the corresponding file into the inbound dir
tt.tic.processor validates the .TIC against the area password table, sniff the file for integrity
tt.tic.processor calls into fpc-bbs's appropriate backend to:
- Resolve the destination file area path for this echo (per BBS config)
- Move the file into that area
- Append the FILES.BBS / DIR.LST entry
- Mark new-file flag
tt.tic.processor then forwards the .TIC to downlinks via BSO, hatching new .TIC files for each subscriber

fpc-bbs is the seam where transport hands off to BBS storage. Same shape as fpc-msgbase is the seam where transport hands off to message storage.

with `fpc-msgbase`

No direct dependency. A consumer (Allfix, future tossers) may use both in parallel: fpc-msgbase for netmail / echomail handling, fpc-bbs for fileecho handling.

with `comet`

No direct dependency. comet handles BinkP sessions; produces inbound files that tt.tic.processor picks up and tt.tic.processor calls into fpc-bbs.

Naming

Unit prefix bbs. —

Namespace	Owner
`bbs.api`	top-level facade, abstract `TBbsBase`, factory
`bbs.types`	shared types: `TFileArea`, `TFileEntry`, `TBbsConfig`, etc.
`bbs.events`	`TBbsEvents` mirroring `TMessageEvents` shape
`bbs.fmt.<vendor>`	per-BBS adapter (PCBoard, RA, Maximus, etc.)

Decision log

2026-04-18 — Repo bootstrapped. Initial high-priority backend list: RemoteAccess, Maximus, Synchronet, Renegade 1.4. Secondary: PCBoard, ProBoard (Allfix already has type defs). Allfix v6 source tree (~/Source Code/originalallfix/) is the primary reference.
2026-04-18 — TIC processing kept in fpc-ftn-transport (as tt.tic.* modules) rather than fpc-bbs. TIC is a wire / file-echo concern, not BBS-side storage. Same logic that put PKT in fpc-ftn-transport rather than fpc-msgbase.
2026-04-18 — User database support (USERS.BBS, USER.DAT) deferred indefinitely. No consumer demand; speculative scope.

4.2 KiB Raw Permalink Blame History