[HECnet] Another sillyness. More information in the nodename database on MIM.

[Brian Hechinger]

On Sun, May 19, 2013 at 02:31:25PM +0200, Johnny Billquist wrote:

In a way it might be important to remember that my nodename database 
extensions right now is just a fun project on my behalf without much 
defined needs. Just like most things people do on HECnet it is totally 
voluntary, and can be considered a pet project without any real demand.

You just described everything we're doing here. :)

I have not really seen any need for this stuff, so it's just for my 
enjoyment. I personally found the INFO.TXT files unsatisfying, so I'm 
doing something else. If it is meaningful or useful is not my primary 
concern. It satisfies me. If it later turns out to be useful, that is 
really cool. The same thing can be said of HECnet in general.

I repeat my earlier statement here. :)

All that said, yes, I could definitely consider a more strict format of 
how something like location is defined. However, you will never see me 
use XML if I can ever avoid it. And it is a really bad fit with older 
computer systems, as it quickly becomes so big.

The same can be said of JSON. If we really want to get fine grained 
information in fields, I would do that natively in Datatrieve. Why on 
earth would I use a silly serializable external representation when I 
already have the data in a database?

I am also against XML and JSON, but for mainly the same reason. CSV can
and will do everything we need here so why overcomplicate it? We aren't
questioning your need for the database or why we want to save things
externally. This is more a means to an end. How do we (meaning all of us
who's names aren't Johnny Billquist) update said database. Giving us
database access is one way, but I'm sure not everyone wants to bother
with that. The INFO.TXT file is a great way for those people to get data
into the database. The more information is in the database, the more
useful the database will end up being.

(And while JSON might be easier for a human to read, it's about as 
unfriendly a XML when it comes to actually manipulating by hand. You 
need tools, and those tools are also just out of the question on 
something like a PDP-11. And I will not write my own.)

JSON is easier to read when you use it for such things as config files.
When you start using it to store rows of data and can very quickly
become less readable, at least when compared to CSV.

Right. And my main concern is actually that people do not have enough 
interest to make this work. So it is either having a project by a single 
individual, or else have something that never takes off.

There are at a minimum two people who are interested to make this work.
I'm one and you are the other. We've proven over the years that we can
be a force to be reckoned with if we so choose. :)

I think also it's not about it "taking off". It's something we put out
there that people use or don't use. We can't (and don't want to) force
anyone into using these tools. We just want them to be available if they
do.

But that is just what I think.

You think too much. :)

So at this point I do not believe in a distributed effort of some sort. 
I also do not believe in doing things in something ugly like XML or 
JSON. I have a database. I can change the schema of that, if needed. 
That is the easy part. The hard part is having data *in* the database 
that is up to date, and in a conformant shape. Neither of those problems 
are addressed by having a schema as such, nor by using some other 
representation.

I'll repeat here what I said before. The proposal is to simply have a
manner of getting data into the database. A properly defined schema for
some file that can be parsed is certainly a good idea in my opinion.

I will start a new thread for the CSV proposal as this one os getting a
tad off track. :)

-brian