[Xastir-dev] Re: xastir server. et-al

[Curt Mills, WE7U]

On 16 Aug 2002, Gerry Wheeler wrote:

> I've long been of the opinion that terminology is important. Certain
> words contain certain implications, or hidden meanings, that can guide
> others in understanding what is meant.
>
> With that in mind, would it be useful to refer to the secondary programs
> (i.e. the ones being controlled by  the "one program" Curt refers to) as
> "plugins"? I don't mean that they need to be implemented in the same way
> as browser plugins. But that term, to me, implies a) a well-defined
> interface between the main program and the plugin, b) an API for plugin
> writers to use, c) some way for the main program to start, stop, plug,
> and unplug the plugins, etc.

Plugins to me mean a monolithic program that can merge various
features in (perhaps at runtime).  Then again, Linux kernel
"modules" do that as well.  Modules can mean other things too.

My current opinion (which may be quite flawed) is that plugins
wouldn't be the correct term.  It would be if we were keeping with a
monolithic user interface that merged in other pieces but basically
stayed as one running program.  That's not what I currently want.

I'll modify my stance just a bit as to what I'd like:

I'd like a control program which could be integrated in with the map
display/user interface portion (or a separate piece) that controls
which pieces of code are running.

This could be as simple as a text config file that the other program
read in order to decide what to do, how to do it, and who to connect
to.  Another GUI program could be the interface for modifying this
file.  One very small daemon could be checking the timestamp on this
file once per minute and if changes have been made,
start/stop/modify other running programs.

It's the usual Unix strategy:  Make small programs that can be
linked together in various ways to perform the larger function.

Think about a program like Samba where you can edit the config file
manually (what I usually do), or use various front-ends for doing so.
If Samba sees that the file has been changed, it parses the file
again and modifies its behavior accordingly.

So for modules, plugins, files, whatever:


  Master config file (plain ASCII text).  Could also embed this
  inside the SQL database but I don't see any point in doing so.
  In fact it would make it harder to run without SQL.

  GUI interface for editing the above config file.

  SQL Database.  Contains all station data.  May contain some/all
  maps or map indexes/extents as well.

  Xastir-SQL daemon to feed and care for the database.  This is
  the long-running daemon.  It'd be good to write this so that it
  would store data locally in files and/or memory (like Xastir
  does now) if the full SQL database is not desired.  It'd also be
  good to write it so that other types of databases could be
  accomodated.  Monitors the config file on a regular basis.

  Interface daemon.  May be part of Xastir-SQL daemon or
  controlled by it, or could be a separate daemon.  Monitors the
  config file on a regular basis.

  Map GUI.  Likely several types of these and/or several instances
  running at once.  Different widget sets, different operating
  systems, differing map views, etc.  Monitors the config file on
  a regular basis.

  Messaging GUI.  Could be part of the Map GUI.  Monitors the
  config file on a regular basis.

  Local map files on the same machine as that running the Map GUI.

  Server map files on the same server as the main daemon.

  And last but not least:  GUI program and probably a bunch of
  associated scripts for preparing and loading map data into the SQL
  database and/or setting up flat file map systems (datum
  conversion, coordinate conversion, renaming, etc).


Some installations might not want to install a full SQL database.
Laptops with limited memory & hard drive space would be likely
candidates for this setup.

The Map program could look very similar to what Xastir looks today,
and various menu selections could bring up other programs, instead
of bringing up other dialogs inside the main program as it does now.
A user wouldn't perceive any difference in operation.  The Map
program would be the main interface for the user, bringing up the
config program and the messaging program from menu entries.

We could also use some other signalling method (like maybe
"signals") in order to alert all of the programs whenever the config
file was changed.  This might not port easily to non-Unix operating
systems though.  We could also keep sockets open for sending
administrative stuff between the modules, or since they probably
will use sockets anyway between them, piggyback those packets on to
the data sockets.

The main Xastir daemon, SQL database, and Interface daemon might
best be started via RC scripts.  As soon as you bring up your
system, Xastir would be running in the background.  You could bring
up your map display at any time to see the current status.  The
normal config program could be make smart enough to enable/disable
Xastir's startup via these RC scripts (requiring the root password
for this operation).

                        .
                        .
  SQL --- XastirDaemon -.--- IfaceDaemon -- Ports & Sockets
            |      |    . |
            |      |    ..|................................
            |      |    . |
            |      |    . `- IfaceDaemon -- Ports & Sockets
            |      |    .
...........................................................
            |      |
            |      `----------,
            |                 |
            |-- Map GUI       |
            |                 |
...........................................................
            |                 |
            `-- Map GUI       |
                | |  |        |
                | |  `-- Msg GUI
                | |
                | `-- Config GUI -> Config_File
                |
  Map Files -> Map_Conversion GUI -> SQL & flat files


Dotted lines are places where it might be nice to allow separating
onto different computer systems.  There are other divisions that we
could do but I'm not sure they'd buy us anything.

I would think that the SQL & XastirDaemon would almost always run on
the same machine.  Usually the interfaces would be on that machine
as well, but you could actually distribute interfaces across
multiple machines.  The Map_Conversion GUI might need to run on
multiple machines as well, particulary if some are stored as local
files on the Map GUI machine, and some are stored on the server
machine as flat files or SQL.

Did I forget any pieces?  If so, let's hear about it!

Curt Mills, WE7U                         hacker.NO_*SPAM at tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U