[Xastir] The future, how soon? B-)

[Jeff Brenton KA9VNV]

[Executive Summary: This message is part rant, part discussion motivation, but
intended in its entirety to push towards modularization of Xastir. The author
has, admittedly, been less active in APRS than I have been in the past, due to
work considerations.]

I will admit that I have not had time to follow things here, despite still
being subscribed to both XASTIR and XASTIR-DEV. Heck, I haven't had a working
Xastir install since my then-primary Linux desktop burned up in January 2003;
other programming projects have gotten in the way. However, some RF coverage
problems (lost high digi sites, making due with less) and reliability issues
(WinAPRS igates don't seem to stay up very long anymore) have me looking at
putting Linux and Xastir back into the mix around here.

But I'm not looking to do the normal user agent stuff for two of the sites.
One I know is probably best served by aprsd (feeding what the digi hears into
internet).

But the other is an RF weather station at the EOC, which only occasionally
needs to display what it hears... but should ALWAYS be sending weather and
LISTENING to the RF side. That's been running Windows 98 and WinAPRS, which
works well enough UNTIL a glitch occurs, UPS drops out, and Windows decides to
pause for a day or five at the "Lost cluster found" dialog box*.

So, what I'm REALLY wondering is, "Just how far is Xastir from having a
daemon-capable part that monitors interfaces, collects and stores data, and
feeds it to the APRS RF and internet networks, and a separate client to
display it?" I.e., how soon before I can put a ITX board with CF disk running
Linux+Xastir next to the transmitter, and everything else on a workstation
elsewhere?

Yes, I know this has been discussed as a "2.0 thing". But casual monitoring of
the lists suggests that, while many here feel it would be a "good thing", it
is only actively thought about when someone asks about using a database to
store the data and running multiple clients with a single RF package, and then
the active developers go back to adding the latest map standard, image type,
or protocol they've discovered to the monolith...

Has there been discussion I've missed, considering how the pieces would work
together? I think this part is vital, even if no actual work towards
separation is being done at this moment, so that work on separation could
progress as time allowed. Without a spec to work with, it's kind of hard to
coordinate efforts.

Maybe the way to go isn't "two" pieces, but multiple, cooperating daemons,
such as a "Davis WX station sensor daemon", "Peet WX station sensor daemon",
gpsd, aprsd, and a "xastird", which connects to and colates the information
from the others into its database, for use by connecting clients.

I've seen discussion over the merits of various databases for storing the
data, including why one is better than the others, and the arguments about "I
don't want to set up a separate database system just to run Xastir!" I think
that modularizing Xastir will "fix" this, in that the database becomes just
another module. Not everyone NEEDS to have the fastest retrieval of spatial
data... So long as it is retriebable. So, if you don't NEED the performance of
PostgreSQL with GIS, you don't have to install it; the "database" could be
abstracted to a log file, or SQLite, or whatever works as a minimum, and you
upgrade as you desire faster performance.

Yes, this is a rather selfish message, in that I don't have the time to help
much with the effort to separate the UI from the back-end, even though it
would benefit me greatly.

-- 
Best regards,
 Jeff                          mailto:ka9vnv at dididahdahdidit.com

* WinAPRS never closes log files prior to a proper exit. I told Keith about
periodically making a copy of the file pointer and closing the copy, but I
don't think that ever made it to their code