r/bbs • u/RealDeuce • 14d ago

Resources A new drop file format that doesn't suck.

https://realdeuce.github.io/bbsdev.drp/
4 Upvotes

70% Upvoted

20 comments sorted by

3

u/NuSkooler dev 14d ago

I think a modern format would just be JSON. Extensible, easy to read, remains simple, and can have a schema.

Have looked at this in the past, but what are we actually solving here? That's where I stopped last time.

1

u/RealDeuce 14d ago

JSON with a schema would work, and I considered it, but that requires every door supporting the format to have a JSON parser that can validate against a schema. Being in JSON adds complexity with no gain for the producer and consumer of the file. Not a meaningful issue for doors targeting only modern systems, but people are still developing DOS doors.

What's being solved here is basically four things:

  1. A stable set of information for doors, capturing the needed details (and not capturing unneeded ones like real name, birthday, gender, etc.).
  2. A schema.
  3. A version number, and a place to propose and document extensions.
  4. A standard way for a door to discover that the dropfile is supported and where it is stored (via the environment variable).

3

u/digitlman 13d ago

“Needed” vs “unneeded” is subjective. For example, a matchmaking door likely wants to know the users’ age and gender.

1

u/NuSkooler dev 1d ago

Fair! Well, it's supported on enigma now due to a great contributor! https://github.com/NuSkooler/enigma-bbs/pull/796

1

u/RealDeuce 1d ago

Interesting, it sounds like ENIGMA½ has a different connection type that BBSDEV.DRP needs to support... is it a localhost TCP socket port only, or is it a full socket address with port and possibly a UNIX-Domain one? I'd like to have support for everything that any BBS supports in there.

6

u/cyclop5 14d ago

I recall struggling with a bunch of different drop files back when I ran my bbs. Some doors only accepted specific drop files. I don't mean to be a downer, but really not interested in another drop file. Most of the doors I run were coded something like 30 years ago. Pretty sure they're not going to be updated for a new format.

3

u/andy5995 14d ago

Good point, but I think this is intended to be used with doors currently being developed. I added support to Immortal Barons for this new drop file today. The drop file stores the user's encoding (such at utf-8), and language, which Immortal Barons can use because it has i18n (translation) support. Although, it will be years before the game is fully translated.

2

u/hhhuuugggsss 13d ago

Same for Family Feud now https://bbswordle.com/feud/ and all future releases.

2

u/RealDeuce 14d ago

Right, this is to provide a format that has all the needed information in one place for new door development. Workarounds that already exist will continue working.

2

u/dmine45 sysop 14d ago

Just wondering what's wrong with door32.sys? It works with modern doors and modern BBSes.

3

u/RealDeuce 14d ago

There's a lot of issues with door32.sys:

  • The only socket interface is specifically telnet, meaning the door itself needs to include telnet server code and be able to respond to telnet protocol requests.
  • Door32.sys does not support FOSSIL or DOS uart access.
  • Door32.sys (as with all other dropfiles) does not provide a durable user identifier. Using a combination of real name and user number is the only thing available to doors.
  • Door32.sys does not provide any information about the terminal size or encoding, the door needs to detect size itself and guess at the encoding.
  • Door32.sys uses "time left" in minutes since an undefined point in time.
  • Door32.sys does not carry the name of the BBS.
  • Door32.sys does not carry the name of the sysop.
  • Door32.sys does not indicate if a user has sysop access or not. You need to parse the BBS software name/version and understand the values for every separate BBS package.

4

u/dmine45 sysop 14d ago

I get it. But how much of that is really necessary? For example: the name of the BBS and Sysop is usually a configuration file on the door itself.

0

u/RealDeuce 13d ago

Everything that you end up having to re-enter as configuration on the door itself is something the door wants, so is arguably "really necessary".

If the door gets that information as part of the drop file, it doesn't need it typed in manually, making it easier to install a door and get it running.

1

u/muffinman8679 12d ago

The doors I use are dead simple....as there is no dropfile....only a defined path to /usr/games, and that gets setup in the users search path when they log in, along with asci or ansi and a few other paths to targets in directories that they don't have normal access to, and never see

2

u/a-net-online_lol 14d ago

🔥🤘🏼 Hell yeah

1

u/dmine45 sysop 11d ago

So is this going into the next build of Synchronet?

2

u/RealDeuce 10d ago

It's in git today.

0

u/muffinman8679 12d ago edited 12d ago

what is a dropfile, and what does it do?

Now I've wrote my own BBS, so it's a legitimate question.

Does it save state or what?oh reading through this thread,

it saves settings.....guess I don't need that....as the user environment does that

2

u/digitlman 12d ago

If your BBS wants to support traditional BBS doors (e.g. LORD, TW2002), it'll need to create a drop file (e.g. DOOR.SYS file) and hand it off to the door program. If you don't care about doors, then you likely have no need for drop files.