[Xastir] boot from external drive?

[Jason Winningham]

On Oct 23, 2007, at 11:00 AM, Curt, WE7U wrote:

> *) DAEMON:  We need a daemon that handles the interfaces, does the
> transmit timing, and talks to a database.

The nice part about this multiple binary approach is that development  
could theoretically start soon, as the daemon could speak APRS-IS  
over a local port and get GUI by talking to the existing xastir 1.9  
server interface.


> *) DATABASE:  The initial database is probably going to be
> PostgreSQL with PostGIS extensions.

I'll have to admit I'm a bit torn on this one - I like to keep things  
simple, and IMO xastir's fairly large number of external support  
packages required are a weak point.  On the other claw, if a GIS- 
aware database results in performance and features worth the effort,  
then bring it on.

> *) GUI:  This is problematic.  Some of the handheld devices are Gtk
> only.  Some are Qt only.

This is a tough one.  The only thing I'll say here is keep support  
package requirements as simple as possible, and whatever we use  
should be fairly easy to get/build/use so that xastir doesn't depend  
on Y which in turn depends on A, B, C, and D.  Something like  
wxPython scares me.  I tried a quick (./configure;make;make install)  
build of wxWidgets on Solaris and on linux, and neither was  
successful.  I didn't try to find out why, but it _must_ be that  
simple to get the support packages or people won't use xastir.

I wouldn't mind seeing a native Mac OS X port (is that Aqua?).

> *) LANGUAGE(S):  Can be different for each piece.  The daemon will
> most likely be written in C or C++.  The GUI pieces may be written
> in several languages as they only need to interface with the Xastir
> daemon API.

Again, let's keep that list short, and use those that are stable and  
portable.  I hate to pick on python, but that's my poster child for  
staying away from some of these development tools.  I have one  
package that needs Python 2.X and others that need 2.Y (where Y = X +  
1), and the two versions are incompatible!  This is a serious  
management headache, and something that should not be inflicted on  
end users.

> While we're at it, I'd also like to import maps and store them in
> our own internal format.  This would allow us to take image maps in
> some other projection and/or datum and convert them to what we need
> for display - ONCE!

Sounds like a good idea.  Could be a big performance improvement, and  
would allow a simpler build for "typical" users, and some of us with  
some processing horsepower and storage could convert to the xastir  
internal format and distribute those converted maps for folks who  
don't  want to do a "full" build.

Another worthy goal would be to allow for binary distributions.  I  
know this can get ugly, but it will increase the user base (and  
hopefully the developer base along with it).

-Jason
kg4wsv