[Xastir-Dev] Short list, stable release, then Xastir-2 development?

[J. Lance Cotton]

see below:

Curt Mills wrote:
> 1) GPSMan integration (DONE!).  Needs testing by other users.

I guess this is new to me. I'll do some testing on this with my Garmin eTrex 
models.

> 3) RELAY digipeat tested for both AX.25 and serial KISS interfaces.
> Someone please test RELAY digipeat with serial KISS interfaces.  I
> think Olivier and one other are testing with AX.25 interfaces.

I can also test this, but I will say that I enabled it recently and as soon as 
a relay-able packet came in, Xastir popped up an error about a hard fail on 
the AX.25 device, invalid callsign of some sort (I can get the exact error 
message when I'm at home this evening).

> I'd like to see the team start on Xastir-2 after the above list is
> complete and the next stable release occurs.  I'm already starting
> to play with PostgreSQL and have a C program compiled already that
> can make a connection to it and get info.  Baby steps.

Excellent!

> I'm looking for opinions on the above short list and where the
> proper cutover point should be for starting on Xastir-2.  All of the
> above is just to get the discussion going, nothing's cast in
> concrete.

My thoughts are that for starters, just the APRS data points received. It 
might be helpful to ask Steve Dimse what his database fields are, since he has 
plenty of experience in a SQL database of APRS data.

Map data can come later. I foresee some utility program that could take the 
various vector map formats and 'convert and insert' them into the map database 
as a common format. Maybe the 'map loader' can even have a gui later on that 
would allow pick-and-choose of shapefile layers to import. (of course raster 
maps need to be handled as well.)

There needs to be a clear distinction from the start of the gui vs. the 
backend data collection. Might as well decide now (or near now) where to split 
the various functions so that there are no grey areas later. Even the backend 
could be made up of several programs, but the first step might best be a 
'collect the data from the interfaces and insert it in a common format into 
the database' kind of thinking.

One question is regarding I-Gating. I-Gating of data should work on the 
incoming (and outgoing) stream. Do we get the stream by repeatedly (at 
regular, short intervals) querying the database for all packets since the last 
query? Do we put the igate code in the 'db loader' program so it has direct 
access to the streams and only use db queries for dupe checking?

discuss ;-)

-Lance KJ5O
-- 
J. Lance Cotton, KJ5O
http://map.findu.com/kj5o-14
joe at lightningflash.net