BBSURI1 // FULL BBS URL W/PORT (telnet://bbs.domain.tld:23)
BBSURI2 // FULL BBS URL W/PORT (rlogin://bbs.domain.tld:513)
BBSURI3 // FULL BBS URL W/PORT (www://www.bbs.domain.tld:80)
BBSURI4 // FULL BBS URL W/PORT (ssh://bbs.domain.tld:22)

I don't think this should be limited either, using any non ancient
format could simply list an array of urls, and a bbs could have 1 - how
ever many.

Andrew


--- MagickaBBS v0.15alpha (Linux/x86_64)
* Origin: HappyLand - telnet://magickabbs.com:2023/ (21:1/126)

On 05 Jun 2020 at 06:26p, NuSkooler pondered and said...

Consider the following JSON (could be: XML (ew!!!), TOML,
whatever):

I think JSON is a good idea. Perhaps there may be other formats
some may think better?? Dunno, but yeah JSON seemed to me (as a
n00b) to be a way of sharing extensible data in a day that software
devs could find it useful.

I agree with JSON being a good idea :) YAML might also be a good choice
due to it's readability and also that it supports comments.

Have a look at: https://www.json2yaml.com/ to compare the two formats

Andrew

--- MagickaBBS v0.15alpha (Linux/x86_64)
* Origin: HappyLand - telnet://magickabbs.com:2023/ (21:1/126)

On 04 Jun 2020 at 11:38p, stizzed pondered and said...

Here is the latest compilation of information we have discussed
including in the new BBSINFO DataFile (whatever form it takes). I am posting this to further the conversation about the standard:

BBSINFO:

Zone // BBS ZONE NUMBER (224)
Net // BBS NET NUMBER (10)
Node // BBS NODE NUMBER (0)
BbsName // BBS NAME (My New BBS)
City // BBS Location (City)
State // BBS Location (State)
Country // BBS Location (Country)
Language // BBS Language (ENG, SPN, FRC, GMN, etc)
SysopName // SYSOP NAME (Johnny SysOp)
Phone // BBS PHONE NUMBER (888-555-1212)
BBSURI1 // FULL BBS URL W/PORT (telnet://bbs.domain.tld:23)
BBSURI2 // FULL BBS URL W/PORT (rlogin://bbs.domain.tld:513)
BBSURI3 // FULL BBS URL W/PORT (www://www.bbs.domain.tld:80)
BBSURI4 // FULL BBS URL W/PORT (ssh://bbs.domain.tld:22)
Nodes // TOTAL # OF NODES SUPPORTED (DIALUP & TELNET)
Callers // AVERAGE DAILY CALLERS TO THIS BBS (25)
Online // BBS Operating Hours-GMT (0000-0000 or 0700-1800)
Software // BBS SOFTWARE (Mystic v1.12 a45)
Delete // FLAG FOR DELETION BY DOWNSTREAM SYSTEMS
Verified // DATE INFO WAS VERIFIED (20200605)
LognType // LOGIN TYPE (1=realname/2=handle/3=choic )
cType // BBS TYPE (1=dialup/2=telnet/3=both

This is unstructured and basically a linear bag of fields;
but almost all structured formats can let you group things
together in more semantically meaningful ways. Consider
the following, in a sort of pseudo-EBNF style grammar:
Let a token be followed by a `?` be considered optional:
that is, zero or one of the token. Let tokens followed
by a `*` be considered repeated 0 or more times. Let
tokens followed by a `+` denote 1 or more. Let
`token1|token2` alternation, or either of those tokens.

ftnAddress := Zone? Net Node Point? Domain?
ftnMember := NetName ftnAddress+
Location := City State Country
Service := Name Host Port?
LoginType := (RealName|Handle|Either)
CharEncoding := (UTF-8|ASCII|ISOLATIN1|CP437)
BBSOtherData := NumNodes? AvgCallers? AvailTimes? LoginType?
BBS := Name SysOp Location? Language* ftnMember* (Phone|Service)+
BBSOtherData? LastVerifiedTime CharEncoding*

I wouldn't bake a "deleted" flag into the data format.
Rather, if one wants to delete, that should be part of
a "delete this entry" sort of thing.

Note that this will map well to something like JSON or
whatever, or even DNS. An example for my system might
be:

"FatDragon": {
"name": "The Fat Dragon",
"sysop": "Dan Cross",
"location": { "city": "New York City" },
"language": [ "English" ],
"charencoding": [ "ASCII", "UTF-8" ],
"ftn": [
{
"netname": "fsxnet",
"ftnaddress": {
"zone": 21, "net": 1, "node": 198, "domain": "fsxnet"
}
}
],
"service": [
{ "name": "ssh", "host": "fat-dragon.org", "port": 22 },
{ "name": "http", "host": "fat-dragon.org", "port": 80 },
{ "name": "binkp", "host": "trunk.fat-dragon.org", "port": 24554 }
],
"otherdata": { "numnodes": 1024 },
"lastverified": "2020-06-06T13:13:13Z"
}

--- Mystic BBS v1.12 A46 2020/05/28 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 07 Jun 2020 at 05:43a, tenser pondered and said...

Fundamentally, you want to describe the data, but in a
structured and semantically meaningful way. The exact
serialization of that data into any particular format
is a secondary consideration.

That said, I would strongly recommend JSON. It's
lightweight, and it's available pretty much everywhere.
It does basically everything you need and can be
upwards compatible if you add things to the schema.

I would strongly recommend _against_ an ersatz format,
or an unstructured line-based thing a la the current
nodelist format.

I've found myself falling down the rabbit hole of wanting to look at how the data could / should be most usefully formatted first rather (e.g. JSON)
rather than focus on what data would be good to allow for and it's structure and semantics. This is not an area of experience I've had much to do with.
But I do take the point about trying to nail down the what before you look at the how. I hope I have understood this difference correctly.

ftnAddress := Zone? Net Node Point? Domain?
ftnMember := NetName ftnAddress+
Location := City State Country
Service := Name Host Port?
LoginType := (RealName|Handle|Either)
CharEncoding := (UTF-8|ASCII|ISOLATIN1|CP437)
BBSOtherData := NumNodes? AvgCallers? AvailTimes? LoginType?
BBS := Name SysOp Location? Language* ftnMember* (Phone|Service)
BBSOtherData? LastVerifiedTime CharEncoding*

YES! And flat...

Not flat, no; notice how the different data nest
within each other. The point is that this describes
the _structure_ of the data, but is independent of
how one _formats_ that structure.

What I'm trying to grapple with is how do we know when we think we have captured enough possible data fields of interest to then be able to move on
to creating ways to store, share and modify it?

I'm also not clear if creating these data fields is a one shot deal or will what we use to store it all in and/or build other things from using the data, allow for new fields to be added e.g. let's say we 6 months later wanted to
add a co-sysop field just as an example..

--- Mystic BBS v1.12 A46 2020/05/28 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 07 Jun 2020 at 04:44p, Avon pondered and said...

I've found myself falling down the rabbit hole of wanting to look at how the data could / should be most usefully formatted first rather (e.g. JSON) rather than focus on what data would be good to allow for and it's structure and semantics. This is not an area of experience I've had much to do with. But I do take the point about trying to nail down the what before you look at the how. I hope I have understood this difference correctly.

That's fair. It's useful to be able to look at examples
to see if all the useful things are being captured.

What vs how is a great way to think about it.

What I'm trying to grapple with is how do we know when we think we have captured enough possible data fields of interest to then be able to move on to creating ways to store, share and modify it?

In short, you don't. The trick is to structure the data
in such a way that's it is extensible in a backwards
compatible way. That is, adding a field shouldn't break
existing software. Formats like JSON are great for
applications like that since each datum is labeled with
a key; things like CSV or other unstructured line-based
formats are terrible since inserting a field between
existing fields breaks all existing software.

I'm also not clear if creating these data fields is a one shot deal or will what we use to store it all in and/or build other things from using the data, allow for new fields to be added e.g. let's say we 6 months later wanted to add a co-sysop field just as an example..

Surely you'll want to add things over time. New services
come, old ones will fall out of use, etc. But by using
a structured data format with semantically meaningful tagging
and by having a well-defined, extensible schema, you can
accommodate those changes as they occur.

--- Mystic BBS v1.12 A46 2020/05/28 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)