Hi there, this is just a comment.
I would like to know what kind of approach would you prefer to use in this situations.
I was using PHP to modify my own database (just a simple file) but now I want to use MySQL. So... I was using libCurl to send the request using POST fields etc.
Now, there is MySQL++, which allows me to send and retrieve info, and I wouldn't need to use PHP or libCurl.
So what of these approach would you use?
Still using libCurl and PHP to learn more about: libCurl, PHP and MySQL
Or just use MySQL++ and forget about: libCurl and PHP?
Personally I would use number 1, because I want to learn more about PHP, but using it for what I see, using PHP as intermediary isn't not necessary so practically it's double work isn't?
]]>PHP+MySQL is insanely easy to learn and use, i've used it to solve countless problems really quickly
]]>Do 'em all.
There's also Boost.Asio for socket programming.
]]>I would say that it depends on the problem. I'm assuming C++ isn't optional then. It otherwise depends on how serious the project is and how much you want to learn. I would say that using PHP as an intermediary you would learn more about libcurl than about PHP. PHP is really easy (if ugly) so it doesn't take much to learn. I imagine the only annoying part about it would be handling errors gracefully. Then again, it does seem silly to require a Web server unless it's actually useful for something. And learning to access MySQL directly from C or C++ is also very valuable knowledge.
]]>2 implies that you need to allow external connections to the database, which in general is not a good idea for security reasons. If you're using a web hosting service (specially if it's free) external access to the database is probably not even allowed.
Option 2 also forces you to GPL your program (unless you buy a commercial MySQL license), if that matters to you.
You can say that option 1 is overkill: having a full web server just for a simple application, though it's easier to implement. There's an option 3, which would be writing your own server software.
]]>PHP+MySQL is insanely easy to learn and use, i've used it to solve countless problems really quickly
Yhea I have been reading MySQL and it's so easy. I have a simple file which consist in this:
name
time
name
time
Like...
Jhone
654
Carl
45
Nigga
789
and it's a really pain to read it from my program, and I haven't done the part where I modify the names and times depending in which is higher using PHP... With MySQL it's much more simple.
after retrieving the file look what I'm doing:
It's really a mess... Since I'm storing the time like: "356 seconds" then I need to convert them to minutes and seconds... I think for all the MySQL is the answer.
I would say that it depends on the problem. I'm assuming C++ isn't optional then.
It's just for my game
Option 2 also forces you to GPL your program (unless you buy a commercial MySQL license), if that matters to you.
Wow, that is really a good point.
Basically I want to add some extra functions to my game, there is already two modes;
Winer Mode: The game takes the best time from the list (which is taken from the server) and start the game in countdown, when the time finish, that means that you're not going to appear first in the list, so it's pointless to still playing.
Normal Mode: The game uses a normal clock taking the time you took to finish the game (answering all the question) and put it on the list if you're in the first 15 best times.
But now I want to add an extra mode, and would be playing with online questions, basically everybody is able to create its own database and connect to it and play with the questions that are registered to that database.
So suppose that someone create the "Hallowing" database and start adding questions to it, if someone wants to connect to that database just introduce the name of that database and connects...
So yhea for all that, I will need MySQL for sure... But using PHP as intermediary would take a little bit of more work but I think it's worth it.
Look what I did! Now my window have little buttons! Yay!
If the goal is to maintain a highscore list, then MySQL is way too large. Have you looked into SQLite? It's perfect for the job - you get one file containing the entire database, and the entire database engine gets linked into your program, so you don't have to make the user install a database server.
]]>If this is for an online high-score list, I would go with PHP + mysql. You should probably never expose a database server to the general population
]]>If the goal is to maintain a highscore list, then MySQL is way too large. Have you looked into SQLite?
Yes, the problem is that my web hosting doesn't support it.
If this is for an online high-score list, I would go with PHP + mysql.
Yhea me to, I'm going to use MySQL + PHP + libCurl. Learning libCurl allows me to get experience in HTTP request while PHP + MySQL give me experience for webs too, you konw, using HTML/JavaScript... instead of C++.
2 implies that you need to allow external connections to the database, which in general is not a good idea for security reasons.
You should probably never expose a database server to the general population
I didn't know those security problems, that is a big problem too...
]]>Yes, the problem is that my web hosting doesn't support it.
Oh, you're on a web host. In that case, I misread your question. If you want to maintain an online highscore list, then the canonical implementation would be a MySQL database, on top of that a PHP web service (don't bother with SOAP, just send JSON data using GET and POST), and then on the client something around libcurl to access the web service.
A particularly nasty problem in this scenario is that you need to secure access to the web service, otherwise anyone can figure out how it works and send spoofed scores, pretty much voiding the entire purpose of the highscore list. You need to make sure that the request really comes from a legit client; unfortunately, there is no 100% secure solution, other than putting all the program logic on the server.
]]>A "good enough" way might be to send on a hash of the data with the request. Maybe a MD5 hash where every other character is xor'd with the other.
]]>Well.... Following the Mark Oates suggestion... I'll use them all... Check this out.
Tools:
C++: We all know why I'm using this.
libCurl: To connect to the server.
PHP: To process the data sent by the program and receive information from the server and the database, which is in another server btw.
MySQL: To store info about High Scores and Question_Packages.
SQLite: People create their own question packages using SQLite, since the SQLite license is very nice I can ship my game along with SQLite without convert it to GPL (thing that I would have to do if I were using MySQL).
So the game should have:
- A SQLite database with the official Question_Packages.
- A panel which connects to the MySQL database and receive info of other "Question_Packages" created by the users. clicking in one of those package will start the downloading process, which will download a SQLite database, and since it's in just one file it's really easy.
- The same panel which shows the Question_Packages should tell you (someway) if you have already downloaded that package or if you don't.
- A panel which allows you to create a SQLite database and then upload it to the server, with fields like "Will your Question_Packages be editable" "username" "password", so if someone download that package and the creator want to make it editable other users are going to be able to add more questions.
I think the MySQL database should have the next fields:
ID, Ques_Pack_Name, URL_of_file, downloads, creation_data, update_data, amount_of_questions, it's_editable, password, Username, description ... and optionally in the same table the 15 best scores but I'm not sure.
The bad news is that there is a loooooooooooooooooooooooooooooot of work.
The good news is that I'm able to do it.
So what do you think? it's too elaborate and unnecessary complicated? or' it's fine.
]]>It sounds reasonable, though I would probably eliminate the "editable" stuff and just make all user-submitted packages editable (i.e., open). It's not like you can really prevent it anyway.
Otherwise, your database schema sounds horribly de-normalized, but I'm too tired and/or lazy right now to actually think about it. You might as well just store a single username/password per user though rather than having them register a new one for each package. Similarly, you don't want to store the high scores in the same table as packages. Without thinking too hard, I can see at least 3 tables: user, package, and score.
Since you will be storing a password I feel obligated to point out that you should never store plain text passwords, especially of users. Salt and hash them (one-way cipher) and store that. Do the same to their inputs when you need to compare for authentication. You might also warn your users not to use "good" passwords so they don't use e.g., their online banking password with your game.
]]>For passwords, crypt with blowfish, 15 or 16 is good right now (later on, you'll need to update this value over time, but that would be in a few years)
The slowest time I have reported for 16 is around 7 seconds (and it's 3.5 seconds for 15)
]]>Have you looked into SQLite?
If the goal is to maintain a highscore list, then SQLite is overkill.
My high-score data stored in a csv, is read, split and sorted using standard STL containers/algorithms, no need for fancy database libraries. Only takes a few lines of code. I then upload scores and download high-score tables using libcurl and on uploading the server splits the csv and sticks it in a mysql table.
]]>