[Xastir-dev] Re: [Xastir] Screen Size

[Aaron May]

On Tuesday 18 May 2004 04:40, Curt, WE7U wrote:

<snip>

> > applications). That's maybe another possibility. Xastir can be resized
> > such way that the map fills the screen while the menu and status bar
fall
> > off the visual screen to utillize the screen maximal for map data.
>
> We could also start a small app that just had the menus and perhaps
> the status bar, then have the map area be a separate window.  That
> might be a lot of work to convert over though, as darn-near
> everything wants to write to the drawing area window, and its
> exact relation to the main app is assumed everywhere.
>

<snip>

Ahhh....

(Let me start by saying that I am not a *nix prtogrammer, and don't know
much
about the inner workings of xastir, but I am an enthusiastic user, and have
read the mailling list long enough to have cobbled together a few ideas)

If you are just going to have 'a wee app', maybe I could poke an idea into
the
system...

[Be warned, its a bit long...]

Xastir Version 2 - Aarons Vision.

Summary:

Split the existing code into three areas, daemon, config and client.

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

Discussion

Client-server architecture is, of course, widely used in *nix. It allows for
a
process to do a particular job, and feed the result to another process. In
my
view, xastir has two main functions; the processing of the various
information from the various interfaces, and the generating of a map from
all
this information.  What the user wants to do with the map, and how they want
to use it and the station information, is the job of other processes. 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.

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

Preserving State.

Preserving the 'state' of xastir, being the stations, tracks, weather and
other status data, does crop up on the web occasionally. I hate to restart
xastir, knowing it would lose its pretty display and all the data. I know
that re-running the log file does something approximate to this, but there
is
no timing in the log file, and xastir thinks that everything happened just
then.

Certainly in a SAR situation, preserving state would be desirable.  We often
setup base in a wool shed (barn)  where power is dubious, and usually
running
off a generator etc. We also have a group of computers for the search
controllers, where it is very desirable to have the map available to each
user.  In the event of the power outage, xastir should pop back up with very
near to the display it had. [Yes an un-clean shutdown complicates things,
lets assume the pc is shutdown  before the power runs out, and restarted in
an orderly fashion ;-) ]

XASTIR-CONFIG

Function:
Configuration of the Daemon functions.  Timings, Interfaces, map file
locations etc. Eventually a /etc/xastird.conf file, with a console/x based
config tool for newbies like me.

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

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.

I mentioned a web browser because its there for everyone (er xastir-lynx?),
but it doesn't allow a great deal of user interface.  So an xastir client
would still be required to get the most out of the system.

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] [er that was written late at night... I
meant,
change the specifically (and exclusively) x-based, not that we shouldn't aim
for
the widest audience]

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?]

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)


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.  I _guess_ that passing a
xpm, png or other image from one tcp/ip port to another is easy, I know that
sending 'commands' from the client to the server is easy, and sending text
aprs packets to a client to display is probably even easier.

The hard part is making up a good protocol between the server and the
various
clients.

I propose a number of protocols need to be supported by xastird, firstly,
the
http (web browser) in simple form, namely the ability to request an image,
given that the client specify a size (x,y pixels,  lat/long/lat/long,
(top/left/bottom/right).

Secondly, an intelligent client, issuing commands, and requesting maps with
specific themes. This would be similar to ftp in that responses are given a
numeric code and a plain english response.  The user could use an interface
dialog on the client that might issue the following commands:

(client commands are prefixed with a >, server responses are not)

>start interface 1
200 OK
>stop interface 2
200 OK
>version
Xastird Version 2.0.1 beta July 2007
>list stations
501 Parameter required
>list stations (wx)
zl3uar-13
>list stations (all)
zl3uar-5
zl3abc
.
>list station-info zl3uar
last-heard: xxx
latitude: xxx
longitude: yyy
blah: blah

Most of you will be cringing about now. I offer the above bits to get the
discussion going, not to lay down the way its going to be...

Some questions:

Should the client have to request everything? Should the server volunteer
the
fact that a new station has been heard, should the client have to process
all
the raw data to decide if it is a new station?

I suggest, with a view to building a client, (if this goes anywhere), that
the
client should request the formated information from the server.  If a user
has a station list open then the client app could request a station list
from
the server every five seconds, and refresh the display with the new info.
When the dialog is closed, I would stop requesting the list.

Like other protocols, it makes sense to allow the client to request a
protocol
version from the server. This allows the client to query the server, and to
only issue commands the server will understand.

Later on, we could devise a few new commands or information steams, that
could
be turned on by the client if required.

Try this:

>protocol
210  1.1 I understand protocols up to 1.1
>open stream info
200 info stream opened;
new-station:zl3uar
wx-data-temp:zl3uar:8C
last-heard:zl3uar:2004-04-01 15:36
...

Thus a stream of data come from the server, in well formated, documented
key:value pairs. The client can action what they like, ignore what they
don't
and keep the display up to date without having to repeatedly query the
server. Just as important, they don't have to deal with the raw packets.
Thats what the server is for.!

>request themed-map
220 Supply theme data
>shape-layers: land:0;water;1, roads;2
>image-width:200
>image-height: 200
>lat-start: 122.45S
>lat-end: 123.456S
>...
>format: png
>overlay: wx-stations, aprs-tracks
>.
200 Image generated, 56,847 bytes transferred.

You get the idea. What do you think?

Cheers
73 Aaron ZL3UAR