That's a good time to make some improvements to it =)
I suggest the following:
Istead of static (correct me if I'm wrong) direction to FU and it's map.html file, make client load on startup XML-like files containig maplists' URL's and their corresponding parsing rules.
Example:
Code: Select all
<server name="TA Spring maplist #1">
<maplist url="http://www.some-host.net/ta/maps-1.html" />
<maplist url="http://www.some-host.net/ta/maps-2.html />
/*this is needed if host has page-separated map list - in such a case, client should download all the pages before processing */
<parse-rule type="map-record">
[some regex or XSL or Perl/other routinne to distinguish from a "map-record" a full complete part of HTML code related to one map]
</parse-rule>
<parse-rule type="map-name">
[some regexp/etc to fetch map's name]
</parse-rule>
<parse-rule type="map-minimap">
[some other regex/etc to fetch minimap]"
</parse-rule>
<parse-rule type="map-URL">
[obviously, download URL]
</parse-rule>
<parse-rule type="map-size">
[YES, PLEASE! Have map size in client's maplist too]
</parse-rule>
[and so on]
</server>
<server name ="#2>
[...etc..]
</server>
The obvious use of this improved flexibility:
1) If one server fails, the maplist is still useful =)
2) If some new server arises (even if it's non-official and even temporary) - it can be easily added to maplist
3) This addition can be community-made, thus not taking developers' time
4) The users can extend maplists and share them. The "official" maplist XML file can have it's permanent address, for example, at Wiki page, so authorized folks can have it updated regularily. Web2.0 tech in action =) (The same thing can be made for MODs, btw.. )
Some other concerns:
* Generally, this mustn't be strict XML/XSL - can be just some .ini file, but XML looks more future-proof.
* The internal map search (in client) can be implemented so search across multiple file lists
* Maybe, you'll suggest a more effective approach to parsing, then making a number of parse-rules (say 1 complex regexp, for example)
* Some error-checking routines must be implemented!
Well, what can The Devs say about this idea?