I started building a chess problem database in the 1990s. At that time it was only meant to be for my use and so I made design decisions based on what I wanted. I decided to include #3, #4, #5 and S#3, which are all genres I enjoy, and I decided not to include twins because of the restraints imposed by Chessbase, the first software I used. In those days Chessbase didn't even have the best database design for its stated purpose of recording chess games and related data, but for chess problems it was an even worse fit. However, nothing else was available and I had no time then to design and write something myself.
At some stage I realised that I could use the database to keep track of problems used in solving tourneys to stop me re-using them by accident. The first effect of this realisation was that I just had to include #2s in the database, and this, somewhat late in the day, is what I did. The second effect was that I had to start recording where and when problems were quoted. This latter decision forced me to think beyond Chessbase and I decided that I might just as well implement everything in the then Borland database package Paradox, which I was already using for other purposes. This was the first of two migrations my Meson database was to undergo.
A few years later, I wished to make some enhancements that Paradox made difficult. In the meantime, during the final seven years of my working life, my employer had taught me how to use Java, a modern, object-oriented programming language that I got to like very quickly, especially when I realised that I could acquire it for free and use it at home! Another piece of free software that I got to know at that time was MySQL, a relational database system that was quite a way ahead of the version of Paradox I had. MySQL was programmable using many different languages, including Java and Perl, another free language that I had found a use for. Given that a later version of Paradox was going to cost me well over £100 and that the other software approach would be free (though subject to more work), I didn't really have a decision to make, especially as I would enjoy the migration work. So, Meson migrated again, and this time the target was MySQL with front-end programming being provided by a mixture of Java and Perl. This is where Meson is today and I am not planning a further migration.
The enhancements mentioned in the previous paragraph were for the automatic classification of #2s (and eventually #3s) with the intention of being able to search for the closest fit anticipations in the database to a given #2. Java has made this much easier to program. It, and MySQL and Perl also, have made it portable too - I've had Meson running on both Windows and on Linux, without making a single change!
Each #2 in the database has a generated solution attached unless it is unsound. Each sound #2 also has a classification field, which is used for anticipation retrieval, and for the search of selected features. Although I wouldn't call this classification work final, it has worked rather well so far. All #3s now have a generated solution attached, if they are sound, and in the fullness of time will have a classification too.
In recent years I have been adding to the database problems with stipulations not so far mentioned, but only if they have been used in solving tourneys. I do not rule out adding any sort of orthodox problem (orthodox board, men and rules) to Meson in the future, but have so far been kept busy enough with the small subset that I have been working with.
I shall be making further changes to the functionality of Meson in the future. These will be listed, before implementation, in the To Do section. When all the current and planned features are available on the website, I shall be pleased to take suggestions for further enhancements from users.
Developed and maintained by Brian Stephenson.