[Xastir] Question/suggestion

[Curt Mills, WE7U]

On 14 Aug 2002, Gerry Wheeler KG4NBB wrote:

> Most of the time, my "ideas" have already been thought of by someone
> else. Keeping in mind that I might just be repeating what went before...

I have two things to say here:
1) Join the club.
2) Great minds think alike?


> It has occurred to me that there should be a way to break apart the
> functional blocks of Xastir, and perhaps some other programs, and build
> them anew so they work together. What I'm thinking of is:

Olivier echoed my thoughts on this.  We've talked about Xastir2 on
the list before, which would be roughly the major blocks you're
talking about, but the main block would be daemon that uses a real
SQL database to store & manipulate the data.  The interfaces portion
would connect to this daemon, as would the user interfaces.
Multiple interfaces and multiple UI's could connect to it at once.
The interfaces could be on different platforms and be written using
entirely different methods and widgets.

The maps could also be served up by this daemon and/or could be
locally owned by the user interface.

We could also have one (or more) GUI's written that would control
and configure the daemon.


> (Curt,
> while you're out on SAR you could use a wireless WAN to receive position
> updates and display them on your PDA.)

Not where we go!  Maybe in the flatlands you could do stuff like
that, assuming you were close to base (what's the point then? hi
hi).


> The real key here is probably the protocol for the messages to and from
> the map drawing program. Unlike APRS, which is limited in size due to RF
> constraints, this would be a network-only protocol. It should be easy to
> generate, easy to parse, not limited or fixed in length. Keeping in mind
> the diverse types of display (screen, web, WAP), it should be kept at a
> fairly high level, letting the drawing program make interpretations on
> how to do the work. If multiple geographic datums are allowed, they
> should be specified in each message.

Yea.  It might also need to be secure, 'cuz some people are going to
want to connect to it from other places (work -> home for instance),
and they won't want people getting in and breaking things.


> One unanswered question (in my mind, anyway) is time. There needs to be
> some way to synchronize timing. Things like automatic expiry times for
> objects would be nice. It would also be nice to play back a loop of
> radar images, for example. Should all the other objects loop too? Each
> frame of the display should be time-consistent, right? But if the
> history of the APRS objects, for example, is stored within the APRS
> program, how would the mapping program tell it what time is being
> displayed? No anwer to that, yet.

The data expiry is easy to handle in an SQL database.  As far as the
map updates, that should be up to each GUI client.  Every one could
choose to do it differently.

If we keep it generic enough, we could perhaps have it sit on top of
various types of SQL databases, and have it run on all kinds of
platforms, choosing the widget set and development environment
that's appropriate for each platform.

Time is the main thing right now.  I'm not sure that with ten
developers working very part-time that we could get this re-org done
in a reasonable amount of time.  The other thing to consider is that
development of new features and fixing of bugs in Xastir1 would come
to a virtual halt during the re-org.

Curt Mills, WE7U                         hacker.NO_*SPAM at tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U