05 Jan 11, 05:19PM
(05 Jan 11, 03:17PM)Drakas Wrote: 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.
Yes I know what you said about output size. But server can performs many tests to avoid abuse (for example, I added a min. of 1 minute by "session".). We can and have to filter what we save.
Also, if XML still needs to be parsed (it's true), many libraries exist for that, which are easily implementable in most of cases, and they're quite powerful ?!
About demos, their format is harder to read... Same problems as we got with XML in worse :s
Thanks for your answer, I hope I'm not going in a totally wrong direction :D