22 May
2013
22 May
'13
10:19 p.m.
On May 19, 2013, at 19:49, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-05-19 20:07, Sampsa Laine 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.
My biggest issues already mentioned earlier are no nearer a solution here, so I'm not
sure I really see any wins for my pet project in doing this.
Don't get me wrong, I'm not saying you need to use this. I'm pushing this as a
part of my own agenda. :)
I have an issue about data content consistency. OS, machine and location information can
vary so wildly it is pretty much useless in a distributed solution as suggested here,
except for people to try and ready and skim through for fun. It will not even be easy for
humans to search through to find something specific. And locations are totally wild.
A system is only as good as its data. If people don't update their file then they get
misrepresented. :)
Also, this do in no way ensure that data is valid or up to date. In fact, as things stands
now, it has less odds of getting it right than my stupid solution of just entering the
data myself, as people in general do report when they add a new machine to HECnet, if they
want anyone else to know about the nodename. Collecting extra information at that stage is
not a big problem.
This also do not ensure that data gets updated when people move, but moving don't
happen frequently, and also even having any data in there is voluntary to start with, so I
guess it's as good as I can expect it to get.
Basically, what you are advocating is the already existing solution of the INFO.TXT files,
which I already have stated that I personally don't feel fits my needs. I don't
mind trying to update my own INFO.TXT file whenever, but I'm sure the format is wrong,
and I definitely do not put all machines in there (and I don't think I've seen
many others doing either), and I definitely do not remember to update that information.
Yes, I'm advocating the existing INFO.TXT solution. I'm just proposing a more
documented data format with some slight tweaks.
But, like I said a number of times now, it's just that I went off on a tangent on a
pet project of mine, and asked people to volunteer information for it. I'm trying to
make it useful, but mostly just for my own amusement to see what I can accomplish. (Hey,
give me a chance to do something under RSX, and I will...)
Sorry, I just sort of used your project as inspiration and ran with it. EVERY project on
HECnet is a pet project. :)
-brian