Close out 0.3.x HWM family — EzyCom remains -1 (no native file)

EzyCom's per-user state lives in the BBS user records, not in
the message base. There is no msg-base-side LASTREAD file to
plumb (cf. Hudson's LASTREAD.BBS or JAM's .JLR). Per the design
principle adopted earlier ("if a format wasn't designed with
HWM, it doesn't get one — that's on the BBS"), EzyCom stays at
-1 instead of getting a faked sidecar.

Final HWM coverage map:

  JAM       ✓  .JLR (CRC32-keyed)
  Squish    ✓  .SQL (CRC32-keyed)
  Hudson    ✓  LASTREAD.BBS (per user-id, per board)
  GoldBase  ✓  LASTREAD.DAT (per user-id, per board)
  EzyCom    -1 BBS-side state, no msg-base file
  Wildcat   -1 SDK has no per-user HWM primitive
  PCBoard   -1 USERS file lastread, deferred
  MSG       -1 spec has no HWM concept
  PKT       -1 spec has no HWM concept

4 native of 9 formats — covers JAM (most common), Squish (second
most), and the QuickBBS family. NetReader and similar consumers
fall back to their own state for the remaining 5 (e.g. dupedb
keyed by area).

README.md feature bullet updated to reflect the four native
formats.

Suite still 40/40 across 9 programs; no code change in this
commit.
This commit is contained in:
2026-04-18 06:21:39 -07:00
parent 850cc65ee3
commit 13ff9bf88a
2 changed files with 7 additions and 5 deletions

View File

@@ -34,10 +34,12 @@ can target a single interface regardless of the underlying format on disk.
publishes its key list via `ClassSupportedAttributes`. Full per-format
matrix in [`docs/attributes-registry.md`](docs/attributes-registry.md).
- **Per-user High-Water Mark** — `base.GetHWM('NetReader')` /
`base.SetHWM(...)` plus auto-bump via `base.ActiveUser`. Tossers and
scanners register as named users in the format's native lastread file
(`.JLR` for JAM, `.SQL` for Squish), so multiple consumers coexist
without colliding. Unsupported formats return -1 honestly.
`base.SetHWM(...)` plus auto-bump via `base.ActiveUser`. Native
for JAM (`.JLR`), Squish (`.SQL`), Hudson + GoldBase
(`LASTREAD.BBS/DAT`, with `MapUser` + `Board` context). Tossers
and scanners register as named users in the format's native
lastread file, so multiple consumers coexist without colliding.
Unsupported formats return -1 honestly.
- Layered locking: in-process `TRTLCriticalSection` + cross-process advisory
lock (`fpflock` on Unix, `LockFileEx` on Windows, `.LCK` sentinel fallback)
+ the existing `fmShareDenyWrite` / `fmShareDenyNone` share modes.

View File

@@ -106,7 +106,7 @@ naturally coexist without colliding.
| Squish | ✓ | `.SQL` (CRC32(lower(name))) |
| Hudson | ✓ | `LASTREAD.BBS` per-(user-id, board); needs `MapUser` + `Board` |
| GoldBase | ✓ | `LASTREAD.DAT` per-(user-id, board); needs `MapUser` + `Board` |
| EzyCom | — | per-area lastread; deferred |
| EzyCom | — | per-user state lives in the BBS user records, not the message base; no msg-base lastread file to plumb |
| Wildcat | — | SDK exposes `MarkMsgRead` per-message but no per-user HWM primitive |
| PCBoard | — | USERS file lastread per-conference; deferred |
| MSG, PKT | — | spec has no HWM concept |