[Xastir-dev] Lurking again and some thoughts

[Dalen Kruse]

About 3 years ago, I had to put my amateur radio hobby on the shelf and deal 
with Real Life.  Having 2 kids and starting a side business will do that to 
you.  I'm now in a position where I can return to my hobby and Xastir was the 
first place I came back to.  It's nice to see the Xastir community is still 
active!

Last night, I spent quite a bit of time combing through the mailing list 
archives to see what I'd missed.  I ran into the long discussion in mid-2008 
about Xastir-NG.  It looked like the Xastir-NG discussions had some good 
points about the direction Xastir should head and what the architecture and 
features should be.  It seems that effort stalled, but I wanted to make a few 
comments.

1.   Almost every time I've seen an effort to rewrite or radically re-architect 
a software product of a reasonable complexity, it either stalls on the ground 
or the end result is garbage.  This holds true in both the open source and 
commercial world.  This isn't to say that these software developers have poor 
skills.  It's just that the effort required is so huge that nobody knows where 
to start.  I'm experiencing this in my own job right now.  In 2007, we 
attempted a complete rewrite (to Java) of a legacy product.  We lasted 18 
months and it was a complete failure.  Our next attempt was to use the legacy 
code, but drastically re-architect it.  It ended up that we didn't have a 
product that we could demonstrate since we broke all of our functionality due 
to the re-architecture activity.  Another failure.  We hit the reset button 
again and we are now doing incremental improvements to the architecture while 
keeping a stable and working product.  We've have more success in the last 3 
months than we've had in the last 3 years.  This is the point I'm trying to 
make: evolutionary changes, not revolutionary, will win out every time.  Sure, 
there are the occasional drastic re-writes that are successful, but they are 
few and far between.

I'm proposing that we take this approach with Xastir-NG.  By looking through 
the archives, I saw several improvements that could be made incrementally.  

Persistence to a SQL database: there's already some of this functionality in 
the code baseline.  Initially support one or two databases with the code 
that's already there.  Start making incremental changes to the code base to 
push more and more stuff to the database.  We don't need a abstract database 
layer right away.  Start off with supporting PostGIS and SpatiaLite.  Add 
others as they are requested or patches are submitted.  With each new DB 
supported, an abstract layer can evolve over time.

OO-design:  It looks like the consensus was to use C++.  Excellent choice 
since C++ interfaces with C nicely.  New features can be implemented in C++ 
while we still leverage all the Xastir goodness we currently have.  If a 
certain existing feature needs an upgrade, take that opportunity to redesign 
it in an OO fashion.

GUI:  This is one that will be harder since I've heard the GUI code is very 
much tied to Motif and the rest of the code.  I would guess the map display 
will be the most complex to change.  Two ways we can go about this: first, make 
incremental changes to separate the GUI/Map from the "backend" code.  Second, 
start shifting all the non-map GUI code over to another toolkit.  I noticed Qt 
was mentioned several times in the archives.  Great choice.  I love Qt.  At 
some point, we could have a hybrid Qt/Motif GUI where all the GUI except the 
map display is in Qt.  Ugly?  Yes, for awhile.  But maybe by that point, we'd 
have the GUI code separated from the "backend" enough that we could start 
working on a new GUI that's more consistent than the hybrid.

2. Now if my advice in comment #1 is thrown out (I won't be offended if it is), 
then the drastic re-architecture could happen.  One thing I notice in the 
archives is the desire to have a modular architecture where we could have an 
Xastir daemon.  It seems that aprsd fits this approach.  I'm not an expert on 
the functionality of Xastir and aprsd, so I could be way off base here.  But if 
I'm not, aprsd could form the basis of a new daemon architecture.  I noticed 
that aprsd development has pretty much stopped for a few years now, so it 
could be something that the Xastir community could take over.  This could also 
be something that we could do with an incremental approach like I outlined 
above.

OK, I'm done with this long-winded message.  I don't want anyone on the dev 
team to think that I'm putting them down.  I'm not.  I'm amazed everytime I 
use Xastir and I greatly admire and appreciate what the developers have done 
with this product.  I'm open to comments/questions/flames.

Dalen

-- 
Dalen Kruse
KC0OVU