[Xastir] GNIS Labels ?

[Curt Mills]

On Sat, 1 Jan 2005, William McKeehan wrote:

> I would love to see the code split to allow multiple clients. The perl
> "client" that I recently wrote
> (http://mckeehan.homeip.net/amateurradio/APRS/aprstracker.htm) has to
> create/decode all of the packets individually; this would have been much
> easier if Xastir had a core that the clients could talk to - especially if
> that core had a perl object interface associated with it.
> 
> This would probably make Xastir a little more complex - especially for the
> windows crowd that are unfamiliar with the concept of a core daemon with
> multiple clients. I run Xastir on both Linux and Windows.

It doesn't have to make it more complex for the user.  You could
start one application that looks through a config file and starts up
the other pieces in sequence unbeknownst to the operator.  The
operator would still think they had a single application running.
This is common in the Windows world.  This could be the default
configuration.  As the user got more sophisticated they'd have more
capability they could draw from.


> You may investigate the plug-in method that UI-View uses, if Xastir is split
> up, it may be able to have something similar.

I was thinking about it from a distributed Unix perspective, where
each piece does a small number of functions and does them well, plus
you don't have to have a GUI client up and running to have an APRS
system on the air and collecting data.  It would be nothing like an
application with plug-ins.

Think about this sort of operation, w.r.t. a Linux box in this case:

You start up your computer, it comes up in runlevel 5 or so.  In the
init.d scripts for runlevel 5 you end up starting postgresql or
mysql, plus then start the xastird daemon.  At that point you're up
and running on APRS, even though you don't have any text or GUI
client up.  Later you can start one or more mapping clients, one or
more messaging clients, perhaps a config client or two, and play on
APRS.  All data that was received while xastird was running is
instantly available to the mapping or messaging clients.  Data will
expire out of the database at the rates that you choose.  Perhaps
you'll keep a day's worth of data, perhaps a week, month, or year's
worth.

If you need to start up a client from work and have it talk through
the TNC's at home, you can.  If you need to change the configuration
at home and restart the daemon, you can, and you would only end up
losing the packets that went across during the restart of the
daemon.

Make sense?  It's much more capability than you'd get with a
graphical monolithic application with a few plug-ins.

Regarding the SQL database:  That's just an example.  We've also
talked about having a shim at that stage that could work with
multiple types of SQL databases, a Berkeley DB database, flat files
on disk, or perhaps an in-memory system as we have now.  That would
make it so that you wouldn't have to use any particular SQL
database, and could customize the system for the type of operation
you desire.

Perhaps for an on-the-road laptop you'd pick an in-memory system.
For an all-out system you'd pick an SQL database as the back-end,
and be able to connect in from remote locations.  In fact, there's
no reason the database, the daemon, or any of the clients have to be
running from the same computer or location at all.  You could have
multiple daemons at multiple sites with TNC's or soundcards feeding
a common SQL database at another site, then have clients connect in
from yet more sites to view the current data and communicate.  You
could feed web pages off the SQL data as well, so you could have
findu-style capability in there too.

-- 
Curt, WE7U.				archer at eskimo dot com
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!"