Ishq wrote:As for the real web integration, this is an interesting feature that has not been explored in depth. Unvanquished may perhaps support MySQL or SQLite in the future depending on large community interest and how well the game picks up.
Okay, so this has been discussed in the past. TheDushan had been doing work on adding support for MySQL in the engine, and the concensus, iirc, was that that idea didn't make any sense for a variety of reasons, and was entirely scrapped. I don't remember what those reasons were, but I'll take some guesses:
-
To have MySQL support in the engine, the client would have to send a password over the network to the database. That means that to protect the password, you'd have to encrypt it. But what's the point of encrypting the password when, as far as I know, there would be no way of hiding it from the user if it is being distributed with the game? (I suppose it's not like we're trying to protect the contents of the database anyway, but still.)
-
The server cannot trust the client, because there is nothing to stop someone from creating a malicious client: instead, the server has to cull malicious requests and only accept those that are legitimate. But if the client is making requests in the form of SELECT statements, all you've done is succeeded in increasing the complexity of validating requests ten-fold: if all requests were handled server-side by a PHP script instead, for example, you would be forced to establish some sort of protocol (in the form of URL parameters) which would be far easier to validate.
-
So we can see that, either way, we're going to have to validate requests, so there's going to be an additional server load aside from just processing the requsts. And either way, we're still going to have to send the requested data to the client, so what advantage does having the client sending SQL queries provide?
Please correct me if I am misunderstanding what is meant by SQL integration.
Little*Butterfly wrote:This restrictions database does not need to be in MySQL. It can be a simple, password-protected, listener daemon equipped with a plaintext file in which player restrictions are stored. I'm thinking something like
{ serial: 05042013-001;
network: 192.0.43.0/12;
restrictions: nobuild, mute;
desc: example.com netblock restrictions;
}
{serial: 05042013-002;
network: 192.0.44.12/29;
restrictions: -nobuild, -mute;
desc: allow our friends from example.com to play;
}
I would suggest JSON (which that very much resembles) as it's easy to parse and, if we wanted a web interface, it'd be much easier to make work. Also, I think it may be a good idea to use an actual SQL database in anticipation of the amount of data growing to any appreciable size.
Gireen wrote:For log rotation you can run this as cronjob every night.
Code: Select all
cp /trem/or/unv/games.log /trem/or/unv/logs/$(date +"%F" --date="1 day ago").log && > /trem/or/unv/games.log
What happens when the file is locked? Would that be an issue? Also, you're not deleting the old log file, so the log file would just grow and grow and grow anyway, right?
Little*Butterfly wrote:Gireen, I was thinking server-side log-rotation to make it easier for MS Windows Unvanquished servers.
And then there's that. I have to agree, I think it makes sense that the engine be able to do that itself. I don't think that would be too difficult, either.