Subj : Re: Proposed Data Structure?
To   : stizzed
From : Avon
Date : Thu Jun 04 2020 19:49:46

On 02 Jun 2020 at 01:35p, stizzed pondered and said...
 
 st> Team,
 st> 
 st> Here is my first stab at opening conversation regarding data structure
 st> 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.

 st>   Net       : Integer;    // BBS NET NUMBER
 st>   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?

 st>   BbsName   : String[30]; // BBS NAME (My New BBS)
 st>   Location  : String[30]; // BBS LOCATION (City, State, Country
 st>   SysopName : String[30]; // SYSOP NAME (Johnny SysOp)

all things I would expect to see, mirrors the key info in a nodelist really.

 st>   Phone     : String[15]; // 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.

 st>   BbsTN     : String[30]; // BBS TELNET URL W/PORT (bbs.do ain.tld:23)
 st>   BbsSSH    : String[30]; // BBS SSH URL W/PORT (bbs.domain.tld:2 )

I wonder if there are other protocols worth capturing? Does for example TOR
count?

 st>   BbsWeb    : String[30]; // BBS WEBSITE URL (www.bbs.domain.tld)

Yep

 st>   Nodes     : String[3];  // TOTAL # OF NODES SUPPORTED (DIALUP & TELNET)

Not of interest to me but could be to some I guess...

 st>   Software  : String[20]; // BBS SOFTWARE (Mystic v1.12 a45)

Yep

 st>   Delete    : Boolean;    // FLAG FOR DELETION BY DOWNSTREAM SYSTEMS

I don't understand that one

 st>   Verified  : LongInt;    // DATE INFO WAS VERIFIED

I guess this speaks to some external checking system right?

 st>   LognType  : Byte;       //  LOGIN TYPE (1=realname/2=handle/3=choic )
 st>   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
state that.

How about something for Networks carried?

Perhaps something for times available if it was say only running weeknights
and weekends?

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
Spanish echos

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 :)

 st> A note on record lengths: It is advisable to limit record lengths
 st> (something Fido wanted to do but by the time they considered
 st> implementation the nodelist was t too large to be considered feasible). 
 st> Remember, in many cases we are working with 80 column displays so field
 st> limits will be important to providing aesthetically  pleasing display
 st> from applications.

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)

.