lp69 wrote:What about this cheap alternative to database implementation: use API web calls.
Usually where there is a database, there is a web server.
So, for example, instead of reading the player account file on disk, PM calls
http://www.mysite.com/getplayerdata.asp ... me=johndoeAnd my web server would be responsible to return information in the format expected by PM.
I would likely never rely on an external system to hold the master database for the poker system. That's for a variety of reasons including performance, security, and technical support issues. Most of my customers want a turnkey system, not a reliance on third-party software. Plus every time I made an internal change to a data field, everyone else would have to go restructure their own database and modified all their code around it. Then the tech support requests come flooding in.
Now on the other hand, I do have plans to add "push" features to the API that the admin can set to trigger on specific events. For example, every time a player joins a table, the server can issue an HTTP call to a selected site with the applicable GET/POST parameters. From there, you can do what you want with that information, including keeping your own database in sync with the master database controlled by the poker server. I may also implement a persistent socket connection for the API on a separate port that could be used for live two-way communication with the poker server.