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 _______________________________________________ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
