Hi guys

Just to follow on from my reply to The Godfather thanks for all of the really good banter on the topic of nodelists and their use (or not) for assorted projects.

As some of you may know I also asked for ideas/feedback over in the Fido FTSC public echo to gauge views on what could be added (and how) to a FTN nodelist to convey extended BBS info.

The general impressions I got from those replies and in trying to sum up
what's been discussed here are (in no particular order)

Current FTN Nodelist
====================

Pros of use

- It's an established document that could be extended if we wish to

- Current U flag could be put to use for assorted new flags such as SSH etc.

Cons of use

- Comes with historical conventions and 'standards' that could limit what we put in it / do with it *if* we desire to negate any backwards compatibility issues for legacy systems. If we didn't care and it's only a fsxNet thing I guess that's a moot point but my take is we want to build something the wider community could embrace if they wanted to use it - right?

- Given differing points of view in the wider community about what a nodelist should be used for (or not). The risk becomes a low adoption of anything
added to it that is deemed unwanted / unwarranted etc. i.e. it's political to use it and not everyone will ever be happy. You get the idea :)

New BBS Information Standard (BBSINFO)
======================================

Pros of use

- Can add whatever data we want to in to this file based on a new schema we agree to.

- Could leverage data from some existing nodelist fields as the basis for populating some of the schema records.

- Can be created with developers needs in mind for mods being discussed now
or to be conceived in the future. i.e. the schema is extensible.

- Can lay out the data in a format(s) to best help developers use the data in way that they can pull it or out of software they create.

Further thoughts
================

It seems adding bespoke flags to the fsxNet FTN nodelist while certainly
doable comes down to a decision about wanting to (or not) move away from the existing FTN conventions established over the years.

If an agreed goal is to create something that can be as extensible as
possible and ideally embraced by future developers and othernets as possible.
I am hard pressed to seeing how the nodelist could carry that mantle as
opposed to something built from scratch.

If the needs right now are for a sound and friendlily researchable dataset
that developers can use as the basis for mods etc. then we are probably
better suited to finding ways to

- create something new and fit for future purpose

- import what we can of use from the nodelist into it. I think it
wise to certainly provision for ways for people to do so

- think of acceptable ways to allow for agreed future extensibility such that once created anything new added to it won't cause the kinds of issues I think we're bumping into by looking at using the current nodelist.

Conclusions
===========

For my part I'm more comfortable with trying to create something new but leveraging any useful data fields from a FTN nodelist to help start to
populate this new file. (we need an importer tool)

I think it helpful to consider finding ways to pull in other data from other authoritative sources like the BBS list that's been being talked about.
(think this is a secondary thing if we start with one network like fsxNet..
but worth exploring none the less)

I'm leaning towards trying to maintain the fsxNet FTN nodelist in such a way
as to keep it as compatible with legacy systems wanting to use it as
possible.

While I/we could add some extra flags to the fsxNet nodelist for SSH etc. without new software to make use of them, and with my general desire to maintain retro compatibility for other software to use the old FTN nodelist.. it feels like the wrong path to tread to give it a 2020 overhaul with tons of new flags etc.

New flags are only helpful / useful if widely adopted and flown. Would they
be if the nodelist was the vehicle? I'm not convinced. Do we risk breaking
some well meaning folks software trying to use such an 'enhanced' nodelist. I fear we would.

Questions
=========

Would the likes of Spec and Stizzed and others be happy to build/modify
the software they are creating on a new BBS Information Standard (BBSINFO)?

All of this is kinda moot if the file is not going to be used for purposes currently under consideration or yet to be imagined :)

If we're happy to move forward on the basis of a new BBSINFO file can we turn our focus to the most useful format(s) of such a file and the metadata schema we wish to develop?



My 2 cents :)

Phew..

Best, Paul

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

Would the likes of Spec and Stizzed and others be happy to
build/modify the software they are creating on a new BBS
Information Standard (BBSINFO)?

I'd be keen if it was in an existing format like JSON or an INI file, it
just would make implementation much easier than writing another parser.

I'd probably write an importer for the builtin magicka BBS list
regardless of what format is used, as it would really just be an
external tool to import a list into an sqlite3 database.

Andrew

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

On 06-02-20 20:39, Avon wrote to All <=-

For my part I'm more comfortable with trying to create something new
but leveraging any useful data fields from a FTN nodelist to help start
to populate this new file. (we need an importer tool)

I agree, the nodelist is a goof place to start for info

I think it helpful to consider finding ways to pull in other data from other authoritative sources like the BBS list that's been being talked about. (think this is a secondary thing if we start with one network
like fsxNet.. but worth exploring none the less)

Make use of the eXperimental part. ;)

I'm leaning towards trying to maintain the fsxNet FTN nodelist in such
a way as to keep it as compatible with legacy systems wanting to use it
as possible.

I'd agree with that.

In the longer term, I see the potential for the new BBS info to generate future nodelists, since the information it contains could be a superset of the nodelist.


... A kid with a hammer will find that everything he sees needs pounding.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

Avon wrote to All <=-

<SNIP>

Conclusions
===========

For my part I'm more comfortable with trying to create something
new but leveraging any useful data fields from a FTN nodelist to
help start to populate this new file. (we need an importer tool)

I agree.

I think it helpful to consider finding ways to pull in other data
from other authoritative sources like the BBS list that's been
being talked about. (think this is a secondary thing if we start
with one network like fsxNet.. but worth exploring none the less)

Agreed again.

I'm leaning towards trying to maintain the fsxNet FTN nodelist in
such a way as to keep it as compatible with legacy systems
wanting to use it as possible.

Strongly concur that the actual *nodelist* should remain compliant
with existing FTN standards. Not doing so can/will break things
for systems still using old/legacy software (which is a
fundamental part of this BBS hobby).

While I/we could add some extra flags to the fsxNet nodelist for
SSH etc. without new software to make use of them, and with my
general desire to maintain retro compatibility for other
software to use the old FTN nodelist.. it feels like the wrong
path to tread to give it a 2020 overhaul with tons of new flags
etc.

No doubt (that it's the wrong path).

New flags are only helpful / useful if widely adopted and flown.
Would they be if the nodelist was the vehicle? I'm not convinced.
Do we risk breaking some well meaning folks software trying to
use such an 'enhanced' nodelist. I fear we would.

As above, we should not risk breaking old software. Yes, a lot of
it could be considered "obsolete", but that's the nature of
BBS'ing and it should be considered as important, IMHO.

The better solution is the development of this new "BBSINFO"
standard, which can eventually be a living document that provides
BBS connectivity info, with selected "nodelist" features as you/we
see fit. Best of both worlds maybe, in the end.

Cheers!


... Toto, I don't think we're in DOS any more...
=== MultiMail/Linux v0.52
--- SBBSecho 3.11-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (21:2/138)

165

Hi guys

Just to follow on from my reply to The Godfather thanks for all of the really good banter on the topic of nodelists and their use (or not) for assorted projects.

<snip>....

New BBS Information Standard (BBSINFO) ======================================

Pros of use

- Can add whatever data we want to in to this file based on a new schema we agree to.

- Could leverage data from some existing nodelist fields as the basis for populating some of the schema records.

- Can be created with developers needs in mind for mods being discussed now or to be conceived in the future. i.e. the schema is extensible.

- Can lay out the data in a format(s) to best help developers use the
data in way that they can pull it or out of software they create.

<snip>...

Conclusions
===========

For my part I'm more comfortable with trying to create something new but leveraging any useful data fields from a FTN nodelist to help start to populate this new file. (we need an importer tool)

I think it helpful to consider finding ways to pull in other data from other authoritative sources like the BBS list that's been being talked about. (think this is a secondary thing if we start with one network
like fsxNet.. but worth exploring none the less)

I'm leaning towards trying to maintain the fsxNet FTN nodelist in such a way as to keep it as compatible with legacy systems wanting to use it as possible.

While I/we could add some extra flags to the fsxNet nodelist for SSH etc. without new software to make use of them, and with my general desire to maintain retro compatibility for other software to use the old FTN nodelist.. it feels like the wrong path to tread to give it a 2020 overhaul with tons of new flags etc.

New flags are only helpful / useful if widely adopted and flown. Would they be if the nodelist was the vehicle? I'm not convinced. Do we risk breaking some well meaning folks software trying to use such an
'enhanced' nodelist. I fear we would.

Questions
=========

Would the likes of Spec and Stizzed and others be happy to build/modify the software they are creating on a new BBS Information Standard (BBSINFO)?

Paul,
You have stated nothing that I can disagree with and (as I have maintained)
I'm simply waiting for a decision to be made. It does sound as though the BBSINFO standard is the direction we might head. I would by ready to proceed with developing that standard should that decision be made (and I think you
are the person to make it). The difficult part now becomes agreeing on a format. apam has suggested ini or json and we could certainly go in either of those directions but I think it should be considered that the flatfile format of the existing nodelist could be maintained to make it easier to update legacy systems. Particularly if we can agree that the first 6 fields could remain? The problem I see with this is that it requires a zone, net, node structure to be retained. In any case, I am onboard with participating in the development of the standard and applications to use it.

.\\ichael Batts
a.k.a. stizzed (because, why not?)
SysOp, The ROCK BBS III

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: The ROCK bbs III - therockbbs.net - TELNET:10023 (21:4/156)