[TangerineSDR] Filename structure, Node info contents, other stuff to ponder

[Rob Wiesler]

(David is probably on the TangerineSDR list, but I don't know that for
sure, so he may get an extra copy of this message (sorry).)

On Tue, May 05, 2020 at 19:06:38 -0400, John Gibbons via TangerineSDR wrote:
> This is intended as a starting point to generate input for further
> refinement, so comments are welcome and encouraged.

I like the base filename structure enough.  In particular, I like that
it's sortable by date in any sane locale, and both the date and the node
ID will align vertically (until 6 chars stops being enough for node IDs,
or we start worrying about the Y10K problem).

Does the date in the filename refer to:
- the beginning of the record, or
- the end of the record, or
- a single day in its entirety, or
- at most a single day, but no (significant) part of any other day?

It's probably obvious to everyone that a "day" is a UTC day, but it's
not in the specification, and it wouldn't hurt to add.

I agree that the zero node ought to be set aside.

We should use another letter or two for the "testing" and high/low-cost
PSWS bits instead of allocating node IDs within specific ranges.  How
about we (where X is 0-9 and * is any (possibly empty) sequence of A-Z):
- use either NXXXXXL or LXXXXX for low-cost  PSWS nodes
- use either NXXXXXH or HXXXXX for high-cost PSWS nodes
- set aside  N00000*, L00000*, and/or H00000* as a test nodes with
  invalid data and/or for other purposes
- not explicitly denote valid data from testing systems in the filename

A couple questions to answer on that subject:
- What makes testing systems with valid data more/less important/notable
  than other systems?
- Can a testing system migrate to a production system without changing
  its node ID?
- Is it sufficient that testing systems will necessarily have low node
  IDs in most cases?

Let's at least specify WWVdata/ as existing relative to "the user"'s
home directory, instead of /home/pi (it can't hurt to be explicit).
Also, you have a typo, where you say that "~" is the "root filesystem
for user", which is not a thing (you mean "home directory").

Is there a reason you're avoiding a second '.' in the filename?  It's a
little awkward to use 2p5 for 2.5, and that second period isn't going to
confuse any software or upend the sorting.

> We should probably create a mechanism for additions / refinements to this
> document for further work rather than this email thread.

We can always have both :)

> I have the original .doc that created this - let me how we should handle
> version control from here.  (Nathaniel?)

Please turn this into a plain text file.  I can read PDFs, but it's not
ideal, and I'm getting sick and tired of specification documents in
other non-textual formats.  A plain text specification file has these
properties:

- Small file size (because this is 2020 and it totally matters)
- Less wasted visual space when the document isn't all that long (again,
  wishlist-grade)
- Universally readable
- Universally modifiable by the recipient (so recipients can offer
  suggestions formatted as a pull request)
- Diffs between revisions can be generated trivially, so that recipients
  can:
  - offer suggestions formatted as a patch
  - figure out what changed without scanning the entire document for
    thin red/yellow lines on a white background (very important to me)
- Mergeable when put in version control (in addition to all the other
  properties above you would want for version-controlled documents)