https://gitlab.synchro.net/main/sbbs/-/commit/81a28642a529ebb45554b394
Added Files:
exec/load/syncretro_getcore.js syncretro_lib.js syncretro_lobby.js xtrn/syncivision/README.md syncretro.example.ini xtrn/syncivision/tests/test_syncretro_lib.js xtrn/syncnes/.gitignore README.md getcore.js install-xtrn.ini lobby.js syncretro.example.ini
Modified Files:
src/doors/syncretro/LAUNCHER.md deploy.js xtrn/syncivision/.gitignore getcore.js install-xtrn.ini lobby.js test_lobby_headless.js
Removed Files:
xtrn/syncivision/syncretro.ini
Log Message:
syncretro: one lobby for every console, and stop re-reading every ROM

Adding the NES meant copying the lobby, the model layer and the core
downloader into a second install directory -- and forking all three
forever. They serve several installs, not one door, so they move to
exec/load/ beside game_lobby.js:

exec/load/syncretro_lib.js discovery, the ROM cache, the activity
store (was xtrn/syncivision/*_lib.js)
exec/load/syncretro_lobby.js the picker, the board, the door command
line -- and it knows no console
exec/load/syncretro_getcore.js the libretro buildbot downloader

The rule that falls out, and is worth stating: a lib serving ONE door
stays in the door dir (syncdoom_lib.js, syncduke_lib.js are right where
they belong); a lib serving several goes to exec/load/.

What remains in an install dir is what is ABOUT that console. Its lobby.js
IS the console definition -- name, core, key profile, what a cartridge
looks like, which BIOS it needs -- and it is code, not configuration,
because an NES is an NES on every BBS. syncretro.ini keeps only what is genuinely a sysop's: [audio], [video], [disc], and [roms] dir/exclude. It
is now seeded from a tracked syncretro.example.ini by the installer, as
the sibling doors do, so an upgrade never overwrites an edited config.

THE ROM CACHE. Drawing the menu opened, read and hashed EVERY cartridge,
every time. The arithmetic was never the cost -- the round trips were: an install is typically an SMB mount, so a remote node paid one open + read + close per ROM just to see the list, and a sysop can feel it. The hash is
cached in data/syncretro/roms.<id>.json, keyed by name + size + mtime, so
a warm run opens exactly ONE file instead of one per ROM. Measured on the
live 198-cartridge set: 212 opens -> 0, 62 ms -> 13 ms even locally, where
an open is cheap. A cold run says so rather than appearing to hang.

The cache is DERIVED, which is what lets it be written with none of the
care plays.jsonl needs (data_dir is shared with a second host): a lost
update costs a re-hash, never a wrong answer. Temp-file + rename; a torn,
stale or missing cache reads as cold.

The NES: xtrn/syncnes -- lobby.js, getcore.js (FCEUmm, GPLv2, fetched from
the libretro buildbot), install-xtrn.ini, the example config. It needs NO
BIOS, unlike the Intellivision; the exception is .fds, which needs
disksys.rom and is therefore out of the default extension whitelist.

deploy.js finds every console install itself (an xtrn/*/lobby.js that
drives the shared lobby -- which IS the definition of a SyncRetro console),
so a console added later gets the binary without editing the deploy step.

plays.jsonl gains a console field, so one append-only log serves them all
and each board shows only its own. A record with no console field predates
the field, when the Intellivision was the only console there was: it IS an Intellivision play, and is counted as one.

READMEs for both installs, in the shape of syncdoom's.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net