[Xastir] boot from external drive?

[Gerry Creager]

<humor=ON>
The old fogie in me would prefer xastird but there _is_ something 
appealing to Dxastir...

I feel compelled to argue in favor of strong support for Fortran as a 
language of choice.  Fortran-based GUIs are, of course, an exercise for 
the truly interested student.
</humor>

I'm really thinking ant for a cross-platform build scripting approach. 
Are we going to advocate Eclipse for the IDE?

I'd like, at this point, to start arguing that if we do adopt our own 
internal format for maps that we produce a product capable of 
interacting with the Open Geospatial Consortium's standards for GML and 
servers.  The list includes WMS, WFS, SOS (weather!), OLS and CS-W.  I'd 
really love to see services included in the mix to allow exporting our 
maps and objects across the 'Net.

I'll also echo Curt's call for enhanced security here.  We likely want 
to invoke some implementation of GeoDRM, even though it's got a lot of 
baggage associated with the name.

gerry

Curt, WE7U wrote:
> On Tue, 23 Oct 2007, Jason Winningham wrote:
> 
>> I'll take this chance to lobby the developers once again to please
>> target xastir 2 to some cross-platform development environment, so we
>> can run native on windows.  I don't do windows, but there are just
>> too blasted many people who do.
> 
> Can't answer your questions about bootable Linux distributions.
> 
> As far as the new development, I'm a proponent of cross-platform
> tools as well, and did the work on the README.win32 document after a
> couple of users reported that Xastir could be run on Windows.
> You're speaking to the choir here.
> 
> I'm not quite in a position to start hacking on new code yet, but
> it shouldn't be too many months longer.  I was mostly silent during
> the last round of "wouldn't it be great if..." discussions about
> Xastir-2 'cuz I just didn't have the time/energy at that time to
> participate.  Or code.
> 
> Current thoughts about the matter:
> 
> *) DAEMON:  We need a daemon that handles the interfaces, does the
> transmit timing, and talks to a database.  This part of it does NOT
> have to have any kind of GUI interface at all, but we could create a
> separate (GUI or text) program just for use in configuring it.  A
> person could choose to run just the daemon and the database and
> connect other clients to it, without running any Xastir GUI clients.
> 
> *) DATABASE:  The initial database is probably going to be
> PostgreSQL with PostGIS extensions.  As we implement this part of
> the code we should code for database independence though, including
> but not limited to MySQL, SQLite, and even perhaps Berkeley DB
> files.
> 
> *) GUI:  This is problematic.  Some of the handheld devices are Gtk
> only.  Some are Qt only.  We currently program with Motif but that
> is not in vogue anymore and lately has been problematic.  Something
> like WxWidgets could also work across multiple platforms but it
> looks kind of "lowest common denominator".  Duplication of the GUI
> programs will probably occur as people may need a Gtk and a Qt
> application for two different platforms.
> 
> *) 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.
> 
> I'm envisioning this as a standard setup:
> 
> - Xastir Daemon.  Because one of my buddies like's to call our
>   project "Disaster", just for fun I'll call it "DXASTIR" for now.
> - PostgreSQL + PostGIS extensions.
> - Messaging/Bulletins GUI:  Gtk and Qt versions.
> - Map GUI:  Gtk and Qt versions.
> - Other GUI's for other pieces we might need:  Gtk and Qt versions.
> - Dxastir Configuration GUI: Gtk and Qt versions.
> - Other GUI pieces as needed (I'm sure I forgot some).
> - "Make" scripts using one of the newer cross-platform build systems
>   perhaps?  Looking for suggestions here:  Automake/autoconf -
>   probably not!  Maven?  Ant?  Others?
> 
> 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!
> 
> Same for vector maps:  Convert them once and be done with it.  The
> vector maps could (should?) also be stored in the database instead
> of as flat files.  That's where the spatially-aware database comes
> in.
> 
> Intended "Make" targets:
>     Solaris
>     HP-UX
>     Linux (many variants)
>     Windows, 98 through Vista
>     Nokia N800/N810 and similar handhelds (Gtk)
>     Qtopia handhelds
>     Others?
> 
> Security of the daemon, database, and API is also a factor.
> Discussions on this are welcome.  I'd also like to have the ability
> to "remote control" the daemon, so that I could change it's
> configuration and have it adopt the new configuration easily, plus
> have a web-based method of showing/manipulating a map screen.
> 
> To be absolutely clear here, we're talking MULTIPLE applications
> here.  A "family" of applications instead of one monolithic program
> that does everything (as we have now).
> 
> --
> Curt, WE7U: <www.eskimo.com/~archer/>     XASTIR: <www.xastir.org>
>   "Lotto:  A tax on people who are bad at math." -- unknown
> "Windows:  Microsoft's tax on computer illiterates." -- WE7U
> The world DOES revolve around me:  I picked the coordinate system!
> _______________________________________________
> Xastir mailing list
> Xastir at xastir.org
> http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

-- 
Gerry Creager -- gerry.creager at tamu.edu
Texas Mesonet -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.862.3983
Office: 1700 Research Parkway Ste 160, TAMU, College Station, TX 77843