05 Jan 11, 03:17PM
It's nice that you've decided to store it in a more accessible format than the current one.
However, knowing that a single server produces so much data in binary [compressed] demo format, I doubt XML would be of any use. The few big disadvantages with XML:
1) It still needs to be parsed (though you wouldn't have to be the one writing the parser). That means that you'd either have to use more and more libraries, and that'd require far more processing power, albeit being easier to use.
2) It will require a lot of storage space. A single (even compressed) XML file with such data will become very large in size. There's no point redundantly storing things like "<frags>123</frags>" when it could be stored as 7B in hexadecimal (look at the length).
3) It can be easily abused: how will you consider, for example, cases where a user joins the server with 14 clients from the same IP with the same name, and then starts changing those names with every reconnection for a 15-minute period?
You really need to revise your model...
And to counter your "advantageous" points:
1) All of that is provided by the demos already, and servers do output those.
2) I don't think unskilled coders should be taking on very large things like ladders. You'll start to get a lot of "trashy" projects coming out of something like this, as opposed to a few good outcomes like what you've worked on as an example.
However, knowing that a single server produces so much data in binary [compressed] demo format, I doubt XML would be of any use. The few big disadvantages with XML:
1) It still needs to be parsed (though you wouldn't have to be the one writing the parser). That means that you'd either have to use more and more libraries, and that'd require far more processing power, albeit being easier to use.
2) It will require a lot of storage space. A single (even compressed) XML file with such data will become very large in size. There's no point redundantly storing things like "<frags>123</frags>" when it could be stored as 7B in hexadecimal (look at the length).
3) It can be easily abused: how will you consider, for example, cases where a user joins the server with 14 clients from the same IP with the same name, and then starts changing those names with every reconnection for a 15-minute period?
You really need to revise your model...
And to counter your "advantageous" points:
1) All of that is provided by the demos already, and servers do output those.
2) I don't think unskilled coders should be taking on very large things like ladders. You'll start to get a lot of "trashy" projects coming out of something like this, as opposed to a few good outcomes like what you've worked on as an example.