webweaving: Overengineering. Because my teeth hurt more than my hands and knees do.
(Obvious brainstorming disclaimer: probably not sensible, much less able to implement with current coding skillset.)
Been rethinking the bot/web bit. Why not have a client app as an additional means of interfacing with the data? Each user will need access to the database query logs for asynchronous replication. (So .htaccess or other password protection, or possibly a Jabber account, or some silly username/submitted password -> username/stored MD5 password check.)
Dynamic DNS - for client apps and the ingame bots. Could use the service at http://www.2mydns.com/domains.asp. Need to detect the public IP address of each client, then perform the update. Each client will also need to run some server code, if attempting the peer-to-peer networking thing. Should at the very least think of having static hostnames resolve to the bots, so that some round-robin functionality can take place, in case the website is not available.
Otherwise, can just get away with each client connecting through Jabber to the website (or similar idea) and not have to bother with the dynamic DNS / IP address / NAT traversal nonsense.
The bots will also need Jabber accounts/client functionality, as should the website. If a client sends an update to the website, the client script on the web server will then relay the message to each of the other clients, except for the originator of the message. Means changing the existing update relay code a bit, but that's something to do another day.
The ingame bots are for relaying messages to non-members, and for a bit o' redundancy. New message notification can take place through the ingame bot (if not logged in with the client app) or just through the client app.
All the actual database querying should take place on the client's local db, not any of the remote ones. This should speed up queries some, though if the db gets big, I'd imagine users not wanting a local copy.
(Side note: some really neat distributed systems stuff.)
Edit for stupid factor: (still in lotsa pain, so probably not making much sense) Can always just connect to the client apps via IP address instead of using a hostname. Durrrh.
Been rethinking the bot/web bit. Why not have a client app as an additional means of interfacing with the data? Each user will need access to the database query logs for asynchronous replication. (So .htaccess or other password protection, or possibly a Jabber account, or some silly username/submitted password -> username/stored MD5 password check.)
Dynamic DNS - for client apps and the ingame bots. Could use the service at http://www.2mydns.com/domains.asp. Need to detect the public IP address of each client, then perform the update. Each client will also need to run some server code, if attempting the peer-to-peer networking thing. Should at the very least think of having static hostnames resolve to the bots, so that some round-robin functionality can take place, in case the website is not available.
Otherwise, can just get away with each client connecting through Jabber to the website (or similar idea) and not have to bother with the dynamic DNS / IP address / NAT traversal nonsense.
The bots will also need Jabber accounts/client functionality, as should the website. If a client sends an update to the website, the client script on the web server will then relay the message to each of the other clients, except for the originator of the message. Means changing the existing update relay code a bit, but that's something to do another day.
The ingame bots are for relaying messages to non-members, and for a bit o' redundancy. New message notification can take place through the ingame bot (if not logged in with the client app) or just through the client app.
All the actual database querying should take place on the client's local db, not any of the remote ones. This should speed up queries some, though if the db gets big, I'd imagine users not wanting a local copy.
(Side note: some really neat distributed systems stuff.)
Edit for stupid factor: (still in lotsa pain, so probably not making much sense) Can always just connect to the client apps via IP address instead of using a hostname. Durrrh.
posted by elegiac at 6:03 AM
0 Comments:
Post a Comment
<< Home