miscellany: need to cache db queries.

Since the db for the site is going to be remotely hosted, it'd probably speed things up a bit to cache some queries to the site, and only perform a query against the remote db if the cached version is too old.

Also wondering about trying the alternative PHP cache. Depends on wherever hosting ends up.

Going to bed, now. Fingers don't work, and everything looks like static. No more coding for me tonight, thanks.

miscellany: some more brainstorming on the various dbs idea

So either I can try to dl SQLite on the server, or I can do some goony crap like have every insert/create/set query be stored in a log file. Have the log file on the game client end translated into MySQL compatible queries. Have the log file on the web server end translated into SQLite compatible queries. Compare the remote and local logs, grab queries if necessary, and then process on whichever machine needs to be updated.

Or, have any db queries be made locally on the game client, then open a connection to a remote MySQL database, and run queries there, too. At least the website db will be current with the local SQLite db. Then only the local db will need to be synchronized.

Either way, will need to make sure queries will run on either SQLite or MySQL. It's reading time again.

miscellany: more stupid database workaround ideas...

Don't yet know if this is feasible, but the bot could keep its own database separate from the one on the site.

Once the bot connects, check to see if the bot's members db matches the members db stored on the site by counting rows. If not, then upload the bot's members db changelog to the bot, and run the changelog through SQLite on the site, or download the site's changelog and process as needed to the local bot. Set up something like a cronjob to do the check/update automatically at a given interval, or on demand by admins.

Then, any queries run on the site will be performed against the db stored on the site, and any queries run on the bot will be performed against the bot local db. So changes won't necessarily be instantaneous between the various bots and the website, but it should be good enough.

Could get really ugly and clunky, but it's a cheapass workaround to having to perform actual db synchronization. Bound to be a problem with a system with a large number of concurrent users, but there isn't any fear of that.

miscellany: need to stop my brain for a few minutes...

Screwing around with the bot code again. And of course, I got to thinking. That's where the trouble starts.

Current crazy idea is this: have the bot have its data stored remotely for some sort of slightly more high availability setup. Something like a paid hosting account with remote MySQL database access. Try and replicate the data to another MySQL database stored on another server (here , here, here, or possibly a combination of all three.) Could also try writing the data locally to a MySQL or an SQLite database.

THEN, have most of the bot functions available through a password-protected website. The password will need to be set in game. Any of the changes made in game or through the web site will show in either interface.

The multiple database setup allows for a bit of redundancy-- could then set up multiple MySQL users with varying permissions. It'd allow multiple bots to access the same data set, which (if anyone were interested) would mean different people could run the bots.

So no more need for one box to stay on all the time. Not that it does, of course.

And no, I'm probably not going to implement this, mainly because I don't know enough about it yet.

-------------------------------------------------------------------------------------------------
Now, not too many people are going to want to run a bot if it's going to be a huge PITA, especially if I'm going to ask them to go and install MySQL, too. So SQLite would probably be an easier pill to swallow, since I could include the dll with the plugins, along with an altered php.ini.

Then, the web end will either need to have the SQLite extension installed, or let users dl() extensions.

Tricky part will be the file synchronization. Either the bot will need to check its file against the one hosted on the site, or I'll have to do some kind of dumb manual merge.

If it's allowed by the host, there's always SQLiteDBMS. And for load balancing, there's SQL Relay. Got a lot of reading to do :D

miscellany: a few web resources

OnLAMP PHP Foundations
Practical PHP Programming
Teach Yourself SQL in 21 Days
MySQL Documentation
O'Reilly Open Book Project
http://www.regular-expressions.info/

miscellany: just testing

miscellany: a few more changes

Added a sig file option for interdepartmental and gridmail.
Comment code for netlog works.
News and report code changed to reflect proper date.

So far, so good. Wish my jaw didn't hurt. Need some sort of rubber chompy dog toy kind of thing to help alleviate some of the teeth grinding.

miscellany: No bot testing tonight, I guess.

!@#! server is down. So since the bot can log in, and I can't, there won't be any testing to see if the new netlog comment code works. Bah.

Guess finding out it's broken will need to wait 'til tomorrow. Or whenever the login issues are resolved. Might as well get on with breaking a few more "features".

miscellany: crazy, now with MELTing eyeballs!

OK, no more coding tonight. Will end up sleeping on my keyboard, and wouldn't that be a mistake.

Started in on the netlog comment code. Added a sigfile option to grid/interdepartmental mail, and links to the passcode, profile, and sigfile plugins to the authenticate menu.

Off to catch a smoke, then some sleep.