On 02 Jun 2020 at 01:35p, stizzed pondered and said...
Here is my first stab at opening conversation regarding data structure
and format for a new BBSINFO standard. This example would follow the
Thanks for putting this forward. :)
I'm going to comment on the fields first as opposed to how they could be captured, their specs etc.
Net : Integer; // BBS NET NUMBER
Node : Integer; // BBS NODE NUMBER
Have you considered Zone? I'm just wondering if it would be necessary to capture that for anything, granted there are a number of zones in use in FTN land and a BBS could be a member of several. Perhaps all the more reason to capture the info?
BbsName : String; // BBS NAME (My New BBS)
Location : String; // BBS LOCATION (City, State, Country
SysopName : String; // SYSOP NAME (Johnny SysOp)
all things I would expect to see, mirrors the key info in a nodelist really.
Phone : String; // BBS PHONE NUMBER (888-555-1212)
I guess, but phone is going the way of the dinosaur. I guess if this is all about trying to provide as much info on a system that *may* offer this connectivity then I agree keep it on the list.
BbsTN : String; // BBS TELNET URL W/PORT (bbs.do ain.tld:23)
BbsSSH : String; // BBS SSH URL W/PORT (bbs.domain.tld:2 )
I wonder if there are other protocols worth capturing? Does for example TOR count?
BbsWeb : String; // BBS WEBSITE URL (www.bbs.domain.tld)
Nodes : String; // TOTAL # OF NODES SUPPORTED (DIALUP & TELNET)
Not of interest to me but could be to some I guess...
Software : String; // BBS SOFTWARE (Mystic v1.12 a45)
Delete : Boolean; // FLAG FOR DELETION BY DOWNSTREAM SYSTEMS
I don't understand that one
Verified : LongInt; // DATE INFO WAS VERIFIED
I guess this speaks to some external checking system right?
LognType : Byte; // LOGIN TYPE (1=realname/2=handle/3=choic )
cType : Byte; // BBS TYPE (1=dialup/2=telnet/3=both
If we have telnet and say phone number defined would we need BBS TYPE?
Not sure if LOGIN TYPE is needed, but yeah can see how some would want to
How about something for Networks carried?
Perhaps something for times available if it was say only running weeknights
Perhaps something to capture some info about the theme of the BBS or assign a number of tags to capture some high level categorization of the BBS
Something to denote Country
Something to capture languages available on the system e.g. English and
Something that could (a bit like the verified tag) show days uptime / last heard from..
Perhaps if the system could report number of callers per day something to capture that, calls per week, per month, year ... most active day, most inactive day of the week.
Just some rando ideas :)
A note on record lengths: It is advisable to limit record lengths (something Fido wanted to do but by the time they considered implementation the nodelist was t too large to be considered feasible). Remember, in many cases we are working with 80 column displays so field limits will be important to providing aesthetically pleasing display
I think as to how the data could be stored, the format etc. I also thought of something like a JSON format that is extensible (and I'm not an active user
of this data format) but my hunch is it would be more useful to contemporary coders as a way of getting data in/out of this file.
To the suggestions of using DNS, yes I also see merit, but I would like to suggest we try to find a way where we don't depend solely on DNS as the solution if we were to apply something being worked on as a file format /
data base to DNS.
Good in my view to have more than one way to get at the data or modify it.
I do like a decentralized approach and wonder aloud how correct data entry of records by those contributing could be for want of a better word policed such that duff or incomplete data was not accepted in any given data field?
If we did use DNS records (and again I am showing my lack of knowledge here) could software
1) scrape a nodelist
2) parse that to DNS text etc records
3) allow people via web admin form/portal to add of amend perhaps not the actual zone file records up front, but edit what the contents of some of the TXT fields would be using some kind of online form?
That software could generate some agreed nightly JSON or similar file that could be peered between a number of systems like a daily master nodelist and used by devs as another source of data for applications to pull info from.
I'm just trying to figure out how data however it is rendered and stored is best updated and by whom and how as time goes by?
So many questions :)
This is fun.
--- Mystic BBS v1.12 A46 2020/04/20 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)