For games I plan to get the CSV file format from play.mg (which for the moment I can't find)
I wasn't aware that there was one. The desktop notifications feature that I wrote for play.mg uses JSON. Use this URL:
http://play.mg/showServersJson.php. For parsing JSON with Python, see
here.
You might also want to consider taking a look at
the desktop notifications script. It automatically recreates the table you see on play.mg and creates desktop notifications (so includes a means of detecting new games). You could use similar functionality in your launcher.
To check for the current version of MegaGlest, consider using GitHub's API.
Here's how to get release data. Here's the exact URL you'd have to use to access release data:
https://api.github.com/repos/MegaGlest/megaglest-source/releases. Note that it's in ascending chronological order. While it technically does include the binaries that get bundled with each release, not every release has every binary, so users would probably need to manually install. Also, it looks like Softcoder released 3.9.2 on Github, but that's not the version on the forum or MegaGlest site (and the release has no binaries).
If you have questions about the masterserver API, let me know and I may be able to help.
EDIT: Obviously the mentioned limitation of using Github's API would prevent the launcher from installing updates automatically. Unfortunately, the INI file that you posted would have major limitations of its own, namely the inability to maintain platform independence (speaking of which, platform independence is why I love using languages like Java or Python over C++). You could work around this, but there's no trivial solution. Possibilities include:
- You could convince the MG devs to make their releases consistent. Have every release (on Github) have bundled executables that have a specific naming format. It looks like they already partially do this, but not entirely. You could try this and if there's no bundled executable, then tell the user they have to manually download and give them a link to the release (although this will fail hard for things like this 3.9.2 issue, where the release doesn't seem to be official).
- You could store these binaries on your own server. Gives you full control, but you'd have to have storage and bandwidth. You'd also have to do extra work on every release (whereas with #1, all the work is stuff that normally is done on every release, anyway).
- The solution that always works: interact with git and download the source code for that release and compile it locally. You'll never have to worry about the release not having bundled executables, since you make your own executables. The downside is that compiling MG can be a pain in the ass, sometimes. You'd need a way to get the dependencies (the Windows dependencies are huge). Windows and Linux currently have different methods of compiling. The first time downloading everything would be very slow, but after that, updates would be very fast. Much, much faster than downloading everything. Some programs take this approach to downloading stuff. Off the top of my head, OS X's Homebrew does this, downloading sources and building them locally instead of downloading prebuilt binaries.
Each of these has pros and cons. #1 is the easiest to implement, but requires depending on the MG team to change their process and stick to it. If they screw up, your program also gets screwed up. #2 is expensive, as you need your own server. #3 is probably the safest approach, but by far the most difficult (not to mention the very slow initial downloading of dependencies and the git repo).
