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

[Gerry Creager]

Aaron May wrote:
> 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.

V2.0?

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

We can generate map snapshots.  That's a picture, not, formally a map.

We can incorporate Mapserver and generate a map with layers selectable 
as needed.  Requires significant coding on xastird, but that's in the 
offing, as a separation as you describe, while very advantageous from an 
efficiency and performance perspective.


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

Sure it does:  http://mesonet.tamu.edu/current-wx.html

But it changes the paradigm.  We'd produce a database (postGIS, for 
instance) or shapefile representation of the data instead of the 
dedicated mapping instance we now have.


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

gnome overhead's legendary.  I expect the kde overhead wouldn't be too 
small either, but I've not looked.


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

And this is in the GOOD THING category.

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

INteresting idea and probably an easier way to progress toward 2.0?  Curt?

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

Think Open GIS Consortium (www.opengis.org) as a starting point, and 
moving data as web map services, web feature services, or web coverage 
services, or as a network-attached-database query.

As a counterpoint... (I like watching Curt pull his hair!)


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

ibid.

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

Look at the OGC specs and web services, and let's talk some more.

It's an interesting set of proposals to get things going!

73, all, gerry
http://mesonet.tamu.edu/currentwx.html
http://mesonet.tamu.edu/svr-wx.html
-- 
Gerry Creager -- gerry.creager at tamu.edu
Network Engineering -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020
FAX:  979.847.8578 Pager:  979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843