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

[Rob Wiesler]

On Tue, May 05, 2020 at 23:01:15 -0400, Phil Erickson via TangerineSDR wrote:
> On Tue, May 5, 2020 at 10:05 PM John Gibbons via TangerineSDR <tangerinesdr at lists.tapr.org> wrote:
>> On Tue, May 5, 2020 at 8:38 PM Rob Wiesler via TangerineSDR <tangerinesdr at lists.tapr.org> wrote:
>>> (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).)

David is *not* on the list.  That's good to know.  Maybe I should stop
my habit of trimming the Cc header so aggressively for this list.

>>> 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?
>
>   Your files only have the YYYY-MM-DD form of the ISO date in them.  This
> seems to imply that there can be only one file per day.  What if the
> instrument dies for a while and then restarts on the same day?  I guess I'm
> wondering why you wouldn't use the fully qualified ISO (e.g.
> 2020-05-05T03:00:00).  Maybe I'm missing something obvious.

This hasn't been answered yet exactly, but the current low-cost PSWS
fldigi scheme rotates the file at the end of the UTC day, so there's a
one-to-one correspondence between UTC day and filename.  This is
entirely unclear from the filename specification, though.

In any case, I find it entirely too likely that we'll see two different
files from nonoverlapping times with the same name from the same node.
Imagine that someone sets up a system, starts it logging, forgets the
root password an hour later, and sets it back up again.  Are we going to
merge the two files upstream?  I would rather not have to.
Misconfigured systems (for instance, cloned systems containing duplicate
node IDs) are something we have to look out for, but this is a case of a
correctly-configured system that just happens to have lost its memory.

Using the full ISO date (minus the (to us) useless time zone offset
portion) corresponding to the time of the first record in the file would
fix this problem.

>>> 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").
>>
>> For the RasPi OS (Linux), I use a system call to define ~ which is the
>> BASE of the user's directory structure (root was a BAD choice here - not
>> intended to confuse it with root user)

It would be even worse to get it confused with the real root directory,
which is "/".  Or with "user root"'s directory, which is typically
"/root" (pronounced "slash-root" to disambiguate).

Don't call it a "base", please.  This one one of those cases where
there's one right term with no competitors.  Just call it the user's
"home directory".

For today's dose of useless pedantry from Rob, ~ is expanded to the real
path of the user's home directory by a globbing function, based on the
value of the HOME environment variable.  Since environment variables are
loaded into the process's memory space literally before they get a
chance to start, this doesn't involve a system call at all (system calls
are a way for userspace processes to invoke functions provided by the
kernel, not a generic term for functions provided by the system at
large).

>>> 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.
>>
>> I stayed away from . and - in the filename as Windows users would get into
>> trouble here (I stuck to just the _ char) and I think we have to cater to
>> that limitation of Windows 7/10/whatever.

Only when renaming files from the GUI does this become difficult on
Windows, and in any case, we don't want users doing that.  Not exactly a
feature, but not a bug, either.

>>>> 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)
>>
>> This will be available online when we get it into version control.

So long as it's not a PDF in version control, please.  The only thing
sadder than a sourceless binary in version control is one that also has
the wrong permission bits set.