[Xastir-dev] Re: Some thoughts: was Re: [Xastir] Screen Size

[Curt, WE7U]

On Wed, 19 May 2004, Aaron ZL3UAR wrote:

> Xastir Version 2 ? Aarons Vision.
>
> Summary:
>
> Split the existing code into three areas, daemon, config and client.

This is what we've been talking about for far too long now, or at
least fairly close to what we've been talking about.


> XASTIRD
>
> Functions:
> * Gathering of information from radio, weather station and other interfaces
> * Output of appropriate APRS beacons to RF/inet
> * Accepting requests from clients for maps, generating and returning the map
> to the client
> * Constantly dumps current 'state' to a file, as to preserve/restore the
> state, upon restarting the daemon.
> (With the exception of the last, its pretty much xastir as we know (and love)
> it, with no user interface.  The vision still stands without this feature, I
> just think it would be good.)

We've talked about having xastird be the piece that feeds an SQL
database and talks to the interfaces.  It would run constantly.  So
would the database.  It would probably have nothing to do with maps
though, as we've envisioned it.  The dumping of the state would not
occur, instead it would be saved in the database.


> Give me
> the freedom to write my own interface, be it a simple script to publish it to
> the web, or incorporating the map display in a search and rescue package that
> does other unrelated (to aprs) stuff.

Exactly.  It would open up a bunch of possibilities that we haven't
envisioned.


> [Should the job of recording the traffic in a database be the job of a
> 'client' or the xastir server?]

Server.  That way the client(s) doesn't have to be connected at all
in order to have data gathering plus message gathering/auto-answer
and automated beacon/object/item transmit.


> Preserving State.

Absolutely critical.  I agree.  We may be able to get this very
easily even with unplanned loss of power via a good database.


> XASTIR-CONFIG

I don't much care how this gets done.  Probably a separate app would
be good, and it doesn't have to be all that much.


> [Note:  I see starting and stopping of interfaces being a client based, real
> time function, not a program configuration thingy. Also note, security
> implications; who should be able to issue start/stop commands over a network
> is also not addressed here.]

Yes, that's one thing that needs to be carefully considered.  We
could of course assume that something else provides the
encryption/authentication, like perhaps an SSH session, then the
application can just pretend that everything is running and
administered locally.


> XASTIR-CLIENT
>
> Now here is were it gets exciting.  I want to point a web browser at the
> xastird port on my server and get a map back.  I want to resize that to fit a
> nice part of the screen and open another map window, showing the whole
> country (New Zealand isn't that big).  I want a third window (a console one
> this time) showing raw packets. I want lots of windows, but even more, I want
> windows on lots of computers (from the one xastird).  The client-server
> approach gives me that ability.

We haven't talked about using a web browser, but that is certainly
something that could be done.  We've talked about a messaging client
(you bring up one client per QSO you have going on), a mapping
client (bring up one mapping client per map you want to see), etc.
Everything would get recorded to/serviced by the database, and you'd
gain a lot of functionality that way which we don't have right now.

We could certainly have yet another daemon that we talked to which
could server up web-based maps.  Once we get to the distributed
architecture, people could run off and design apps to do all kinds
of special-purpose things.


> Xastir, over the years has been specifically x-based, not relying on kde or
> gnome libraries.  This has meant, among other things the widest audience, and
> things have been nice and simple. [Should we change, I vote yes, but I
> appreciate the other point of view]

I vote no, or at least I think the basic functionality should not be
tied to a specific GUI library.  If people want to run off and
create separate clients which use various GUI libs, that's great and
I highly encourage it, but for the basic functionality we should
concentrate on the widest possible audience.

I could see creating a Windows-specific GUI app at some point
(probably not me doing it, but I'd hope somebody would), a Gnome
app, a KDE app, a plain-vanilla app, even perhaps a Perl/Tk or text
application.


> Splitting the code into server-client bases, means that people can develop
> small laptop clients or big meaty gnome clients.  Clever people can add bits
> to the engine (xastird) without worrying about a menu or dialog box, the rest
> of us can tinker with a pretty little gnome client, and read up on a protocol
> (see below) to talk to the xastird.  We could even have a ms windows client,
> (I could do that in Visual Basic quite nicely. (flames > /dev/null)).  [Along
> that line of thinking, could xastird ultimately compile under ms c++ as a
> windows service?? with a windoze client?]

There you go.  We're all thinking alike, and this has all been
discussed before over the last 2 or 3 years.


> HOW TO PROGRESS
>
> The best way I can think of to proceed, would be to simply build into the
> current program a tcpip port to listen for requests, and serve them.  In
> time, when the protocol and functionality is defined, and largely useful, a
> --daemon switch would allow an xastird script to run the xastir app without a
> UI. As the client(s) got better,  Xastir could loose its UI capabilities all
> together, truly becoming a daemon and being a lean mean machine, which along
> with a small client could become an ideal thing to run on a low spec laptop
> or an embedded Linux device. (yummy)

I'd prefer to start from scratch, and design a MySQL or PostgreSQL
database setup with an xastird daemon to feed it.  We then connect
our current Xastir to that, and then start splitting the current
Xastir into the various GUI front-ends we need in order to duplicate
our current functionality.

We could also stick our maps in the database and convert them to the
proper datum/projection on import, plus change the info into
something that Xastir can use directly instead of having to convert
each time a map or new view is enabled.


> PROTOCOL
>
> Assuming you are still reading...
>
> The biggest problem (Curt is probably pulling his hair out by now!) as I see
> it is the communication between server and client.

Actually it looks like I'm the _only_ one reading it, as you sent it
to me and not to the list...

I'm going to skip the protocol stuff for now, as I think we need to
decide on the architecture first, then we need to worry about the
nitty-gritty protocol details.

Send your note to the list (developers list please), and either you
or I can forward my response after that.  We'll get this discussion
going again.

--
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!"