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

[Curt, WE7U]

On Sat, 12 Jun 2004, Jeff Brenton KA9VNV wrote:

> 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.

I've been moving this along in my INBOX so that it didn't get
forgotten.

Yes, you're right, it has been discussed several times over the last
two or three years.  I'm often the one bringing it up.  It usually
gets talked about for a bit, then forgotten again, as the developers
get busy doing other things.  It would take a major effort to break
away from the bug-fixing and the adding of yet-another-feature in
order to start on version 2.0.  It needs to be done though.

Here's what I currently envision:

*) Storage module.  This can be flat files, db files, SQL Database.
Should have a single API for the other pieces to talk to so that the
back-end can be replaced easily.  It should serve up maps as well,
either from local files or from the database.

*) Map import module.  This is used to suck in map files, convert
them to a very fast access format, and send them to the storage
module.

*) xastird.  This talks to 'net, TNC, weather interfaces and to the
storage module.  This and the storage module are the long-running
pieces of Xastir-2.0.  The other pieces can come and go (may be
extremely short-lived).

*) Message client.  This talks to the storage module and allows
sending receiving bulletins and messages.  Multiple clients can be
run at the same time.

*) Map client.  This talks to the storage module.  Multiple clients
can be run at the same time.


We could separate out the various types of interfaces in xastird,
but I don't currently see a need to do so.  I think one monolithic
piece for that might make sense, at least for now.  Because that
stuff is multi-threaded though, it could make some sense in the
future to fully separate them into different processes.

I think where we left off last time was that I was going to try to
separate out the interface stuff from everything else.  I never
found the time to do so.  I would think that to be a logical first
step, then try to separate out the storage from everything else.
Once that is done, we can try to make the storage piece into
something that would work for multiple storage methods.

One big question in my mind is security:  How do we connect all
these pieces on the same machine or on different machines yet keep
unauthorized people from messing with them?  We need a method that
works across all platforms.

--
Curt, WE7U			         http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"