On Sun, 19 May 2013, Johnny Billquist wrote:
On 2013-05-19 18:14, Brian Hechinger wrote:
On Sun, May 19, 2013 at 05:02:18PM +0100, Robert Jarratt wrote:
Well, if the separator is | then it isn't a CSV file :-)
While I do understand the origins of the term CSV, the C really doesn
stand for character. Tabs are used quite commonly as well as commas. Any
character is valid, so long as it's accepted by all consumers of said
file.
The C standing for comma is antiquated and outdated and should be
changed. In my not so humble opinion, anyway. :)
He says, to a crowd of people running antiquated and outdated software
and hardware... :-D
Anyway, while I think I agree that technically, C stands for comma, I
also think | is a better separator in this case.
Feel free to call it anything. The acronym for the format is less
important. We could call it BSV then.
I'd find | easier to read in this case.
We could call it SSV. Separator-separated values. That's pretty all-encompassing.
I have no issue with this except that allowing the columns to appear in any
order, while nice and flexible, makes it harder to write the software. It
does not seem worth the effort to have that flexibility given the low
enthusiasm for writing this software, so a simplification would be to fix
the column order.
It really isn't that hard to write. I've implemented such a thing in many
languages (including very stupid ones) and it is *always* worth the effort.
I honestly don't know what I think on that subject. Or, actually, I do.
I think it would be even better to just have key-value pairs. Why
overcomplicate things?
Any unknown key is just ignored. We could expand with new keys without
having the code synced. And then the values can hold any character
except newline.
Actually I am thinking that I wouldn't mind writing the program myself, but
don't wait for me, I have a host of other things I want to do as well.
I'm always open to writing anything. :)
Knock one out for RSX? :-)
I'll try and get back with some more thoughts about file formats and
whatnot in a while. My pizza just arrived...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
On Sun, 19 May 2013, Brian Hechinger wrote:
CSV as a data format is actually quite powerful, flexible and simple.
Let's just use Excel 97!
In order for it to work, however, we need to agree on some ground rules.
The ground rules are simply this:
1) The first line must *always* be the header. This is not optional.
2) The field separator must be chosen.
3) The names of the columns must be decided on.
4) The column names should be case insensative.
5) The columns need to be defined required or optional.
6) This all needs to be documented somewhere.
#6 is a provlem I've noticed with INFO.TXT. There's no order.
The reason for the header being required is you can do column name to
column position mapping. This makes the CSV column layout not fixed. The
columns can be in whichever order each person finds appropriate.
#2 is pretty much already chosen as | seems to be the most common one
(one of my favorites as it rarely appears in text).
There are some already commonly used column names at this point, so we
should make a list of what those are and which we are going to use.
I think the rest are self explanatory. :)
Let's discuss!!
-brian
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
On May 19, 2013, at 1:34 PM, Sampsa Laine <sampsa at mac.com> wrote:
On 19 May 2013, at 19:32, Brian Hechinger <wonko at 4amlunch.net> wrote:
I'm happy to write a doc describing the format we eventually settle on.
If you want to, feel free. You probably have more free time than I will
over the next several weeks.
-brian
Actually I'm quite busy with a client project but am happy to do this, if there's any significant take up.
How many HECnetters would participate in creating INFO.TXT's for their areas / boxes?
+1
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 19 May 2013, at 19:32, Brian Hechinger <wonko at 4amlunch.net> wrote:
I'm happy to write a doc describing the format we eventually settle on.
If you want to, feel free. You probably have more free time than I will
over the next several weeks.
-brian
Actually I'm quite busy with a client project but am happy to do this, if there's any significant take up.
How many HECnetters would participate in creating INFO.TXT's for their areas / boxes?
sampsa
On Sun, May 19, 2013 at 07:29:24PM +0200, Sampsa Laine wrote:
On 19 May 2013, at 19:27, Brian Hechinger <wonko at 4amlunch.net> wrote:
Mmmm, pizza. I just had home made Feijoada. :)
-brian
I LOVE feijoada, must see if there are any Brazilian restaurants in Brussels.
Do it! My mother in law made some because she knows how much I like it.
:)
-brian
On Sun, May 19, 2013 at 07:23:00PM +0200, Sampsa Laine wrote:
1) The first line must *always* be the header. This is not optional.
This has already sort of been defined, i.e.:
ADDR |NAME |OWNER |EMAIL |HARDWARE |OS |LOCATION |NOTES
2) The field separator must be chosen.
I think we've settled on "|", no?
I addressed these later in that same email. :)
Yes, "|" and yes those are the headers I was thinking of.
5) The columns need to be defined required or optional.
Do we do this in the header or in the documentation?
In the documentation.
6) This all needs to be documented somewhere.
I'm happy to write a doc describing the format we eventually settle on.
If you want to, feel free. You probably have more free time than I will
over the next several weeks.
-brian
On Sun, May 19, 2013 at 05:45:51PM +0100, Robert Jarratt wrote:
I didn't want to start a big debate about this, it was just a little joke. I
would be more than happy to use the pipe symbol as the separator.
Eh, you didn't start anything. That's just me being my usual self. :)
It wouldn't be a big effort for me on the platforms I write for today. It
would be harder for me on platforms I programmed a long time ago (or even
never in the case of RSX) and never having programmed for Datatrieve, but
that is precisely why I would like to do it, although I am not at all sure
about the RSX hurdle.
It's a pretty simple thing to write, over all. Associative arrays make
it a ton easier, but it's not that hard even when you don't have those.
Is there a language on VAX that would make it easier to port it to RSX? Or
can Datatrieve be accessed over DECnet so the scraper code runs on VAX and
populates Datatrieve on RSX?
I believe there is a Datatrieve client for VAX but I seem to remember
something about it not working correctly? I'm not sure though.
-brian>
On 19 May 2013, at 19:27, Brian Hechinger <wonko at 4amlunch.net> wrote:
Mmmm, pizza. I just had home made Feijoada. :)
-brian
I LOVE feijoada, must see if there are any Brazilian restaurants in Brussels.
On Sun, May 19, 2013 at 06:34:14PM +0200, Johnny Billquist wrote:
On 2013-05-19 18:14, Brian Hechinger wrote:
On Sun, May 19, 2013 at 05:02:18PM +0100, Robert Jarratt wrote:
Well, if the separator is | then it isn't a CSV file :-)
While I do understand the origins of the term CSV, the C really doesn
stand for character. Tabs are used quite commonly as well as commas. Any
character is valid, so long as it's accepted by all consumers of said
file.
The C standing for comma is antiquated and outdated and should be
changed. In my not so humble opinion, anyway. :)
He says, to a crowd of people running antiquated and outdated software
and hardware... :-D
Maybe I worded that wrong. An antiquated and outdated term that was
incorrect shortly after it was created. There's a big difference there. :)
Anyway, while I think I agree that technically, C stands for comma, I
also think | is a better separator in this case.
Feel free to call it anything. The acronym for the format is less
important. We could call it BSV then.
I vote HSV. HECnet Separated Values. That way we can use whatever the
HEC we want. :)
I honestly don't know what I think on that subject. Or, actually, I do.
I think it would be even better to just have key-value pairs. Why
overcomplicate things?
The problem with key-value pairs is they work great for single sets of
data but quickly turn into either INI files or something that quickly
aproaches being similar to JSON. CSV (sorry, HSV) is nothing more than a
simple way to store multiple sets of key-value pairs.
Honestly, this is all a moot argument considering the fact that your
data format needs to match whomever you want to be able to read it. If
you don't care that I can read it, well then it doesn't really matter
does it? :)
Any unknown key is just ignored. We could expand with new keys without
having the code synced. And then the values can hold any character
except newline.
This is pretty much what header indexed CSV gives us.
Actually I am thinking that I wouldn't mind writing the program myself, but
don't wait for me, I have a host of other things I want to do as well.
I'm always open to writing anything. :)
Knock one out for RSX? :-)
Gladly! Once I have more time (give it a month or so) I'd be more than
happy to take a stab at writing stuff for RSX/RSTS/etc.
I'll try and get back with some more thoughts about file formats and
whatnot in a while. My pizza just arrived...
Mmmm, pizza. I just had home made Feijoada. :)
-brian
On 19 May 2013, at 19:17, Dave McGuire <mcguire at neurotica.com> wrote:
I like it.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On May 19, 2013, at 11:03 AM, Brian Hechinger <wonko at 4amlunch.net> wrote:
CSV as a data format is actually quite powerful, flexible and simple.
In order for it to work, however, we need to agree on some ground rules.
The ground rules are simply this:
1) The first line must *always* be the header. This is not optional.
This has already sort of been defined, i.e.:
ADDR |NAME |OWNER |EMAIL |HARDWARE |OS |LOCATION |NOTES
2) The field separator must be chosen.
I think we've settled on "|", no?
3) The names of the columns must be decided on.
See 1
4) The column names should be case insensative.
No issue with that.
5) The columns need to be defined required or optional.
Do we do this in the header or in the documentation?
6) This all needs to be documented somewhere.
I'm happy to write a doc describing the format we eventually settle on.
