Sadly, I don't know much about installers like install Jammer, but it looks quite promising. Another thing that I would like to do with the next minor version of gae (0.2.13) is include more language support out of the box and maybe even a subset of the most popular maps & tilesets? I dunno. Again, I'm starting to think that a centralized repository for installing mods is pretty important to attracting more people to GAE, by making more content available without having to search through forum postings to find them and then find out if they work or not.
As far s the "Fetch URL" thing, if we weren't having to talk about windows, that's as easy as putting "wget
http://my.site.com/my/url" in a script.
So as far as being able to download mods from in-game, just get us a nice, XML-configurable GUI setup and the interface to do it wont be too difficult, although there are a lot of steps to perform. There are 20 gazillion libraries to fetch files off the net (CURL & such). I'll have to think out how the server end will work, we would probably want to have a simple table in a database that has each mod with the name, version, author(s), filename (on the server), date published, number of downloads, etc. and then a simple php or some such to return a XML document from the web server with that info. I don't know php, but I know how to do that type of stuff in Java/jsp/servlet, etc. -- which I personally think is a lot of work for just one page. But we have to work out a scheme for add-ons whereby GAE has some type of registry so it knows what's installed, what version of it is installed, etc. Then the GAE client can retrieve the list from the server and tell the user what upgrades are available for what is already installed and what add-ons are available to be installed.
I'm personally inclined towards the approach that Wesnoth uses where each add-on has it's own directory and then the directory it has it's maps, tech trees (a.k.a., "Eras"), etc. are added to a search path (ala physfs). Also, if we do use physfs, we don't even have to unpack the mods, we just keep them in a .zip archive (wont work with tar/gz, tar/bz2, etc., but it does also support .wad, .hog, e.t., a.l.).
I am going to still be focusing most of my time on the networking stuff. But the GUI needs to be there to make the rest of this feasible, because the current process for creating new GUIs is just too ugly. =( What I think we need for the new GUI library is a mechanism whereby we generically state (in C++ code) what data fields and operations each GUI interface has. Then, however the GUI is defined (XML, etc.) it can specify the relationship between the interface code and the GUI definition, so multiple skins can exist for the same GUI screens and they can be completely different (as long as they still fields for all data and buttons or whatever for all operations). Sorry for going a bit OT with that, planning out what we want to do and how we're going to do it is important for deciding how much we want the installer to do. I guess, in the end, I'm not terribly opposed to the installer downloading mods if it's just a matter of downloading them and sticking them in a directory.
