OK,
Here's a really quick draft of what I'm thinking, feel free to add your thoughts
The parseable info begins with ".BEGIN-HECNET-INFO" and ends with
".END-HECNET-INFO"
The following columns must be present and named in the first line of the parseable block:
- ADDR - DECNET address of host
- NAME - DECNET node name of host
- OWNER - Person who owns the box*
- EMAIL - Contact email for the box's admin*
- HARDWARE - What hardware the box is running*
- OS - What operating system / software stack the system is running*
- LOCATION - Textual location of box, optionally long/lat info in some sane format*
The fields marked with an asterisk can be left empty but must be present in the header.
Example:
.BEGIN-HECNET-INFO
ADDR |NAME |OWNER |EMAIL |HARDWARE
|OS |LOCATION
|NOTES
8.401|CHIMPY|Sampsa Laine |sampsa at
mac.com |AlphaServer DS10 |OpenVMS
8.3 |London, England |Main SAMPSACOM system, SMTP gateway
(
CHIMPYMAIL.COM)
8.400|GORVAX|Sampsa Laine |sampsa at
mac.com |SIMH VAX on OSX/Intel |OpenVMS 7.3
|London, England |MULTINET bridge to Area 2, Area router
8.403|RHESUS|Sampsa Laine |sampsa at
mac.com |HP rx2600 Dual 900MHz |OpenVMS 8.4E
|London, England |File libraries available
8.500|PYFFLE|Sampsa Laine |system at pyffle.com|VMWare
|Ubuntu+Pyffle BBS |London, England |Waffle
reimplementation BBS, log in as pyffle for access
.END-HECNET-INFO
On 19 May 2013, at 20:07, Sampsa Laine <sampsa at mac.com> wrote:
On 19 May 2013, at 20:03, Cory Smelosky <b4 at gewt.net> wrote:
On Sun, 19 May 2013, Sampsa Laine wrote:
On 19 May 2013, at 19:58, Cory Smelosky <b4 at gewt.net> wrote:
#6 is a provlem I've noticed with INFO.TXT. There's no order.
When me and Steve Davidson originally thought of adding parseable info to INFO.TXT we had
the idea that the file itself would be free-form text with a machine parseable block at
the end, with delimiters.
If you look at
http://rhesus.sampsa.com/cgi-bin/hecnetinfo/hecnetinfo.com?q=chimpy
you'll see what I mean, there's a clearly defined block of machine readable CSV at
the end.
How many people followed that though?
No idea - I don't think anyone ever wrote a parser.
But here's a brief outline of how I think this should work:
1. Someone (=me) defines the CSV format formally in a document
2. This document is passed around and corrected until majority is happy with it
3. Someone (=brian) writes a parser
4. People nominate boxes from where their INFO.TXTs should be pulled (one can cover a
whole area or even more)
5. This is integrated into the DB using the parser from 3 periodically.