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