Technology Choices

The cross-platform GUI toolkit

There are two technologies that I consider fairly obvious for this work. the first is the cross-platform GUI toolkit. As far as I can tell, there are really only two contenders out there. The first is QT and the other is the Eclipse RCP. I am planning to use the RCP simply because it does much more out-of-the-box and it is written in Java, which I am far more fluent in nowadays than C++ or C ( besides, I never had a great love of tracking memory allocations).

There are some downsides, especially speed of start up and memory footprint.

pros: Well known, decent performance on most systems, designed for exactly this.

cons: A large memory footprint, a serious learning curve, and potentially slow startup.

The persistent storage

The second technology is what to use for the persistent store. This is a little less obvious, because there are more choices and a lot more variation within the choices. To start with the biggest issue is whether or not to use a relational database. relational databases are very good at what they do and have very well known scaling and programming issues. if I decided to go with Hibernate or JPA I would have a wealth of technical support at my fingertips from their very active user base. The downside is that for managing hierarchical metadata the relational database is not a great choice. In effect, I would be using the relational database for something it's not really designed to model. It could certainly be done using Hibernate or JPA but there would be a perceptible cost in design to fit, maintenance time, deployment issues, and possibly performance.

Since the problem I am dealing with deals with relatively small numbers of objects, intricately linked, it makes sense to go with an object database such as db4o. I looked at several, but db4o's defaults fit in well with my intention to keep things as simple as possible.

I am very interested in any thoughts people have about modeling hierarchical relationships with their preferred databases.

pros: Very natural fit for object persistence. Uses annotations and very simple defaults to make things work. Less resource intensive than most relational databases.

cons: Not as well known or as understood as relational databases. It also has a smaller user community.