Now your talking about the improper use of a jabber client.
It's only "improper" based on the current server implementation. There's nothing architecturally wrong with it at all. In fact, it's architecturally superior because it's much more modular: it allows the bot to run on a separate machine from the server (anywhere on the Internet in fact), doesn't require any server reconfiguration, and will [barring scale issues] work with any conceivable Jabber server architecture, even ones that don't have the same internal design as the current one.
Thats why that bot should actually be running off of a
transport that is written specifically to handle that kind fo traffic. Most
likely storing the user data in some sort of in memory database, while
persisting some of the data it requires for operation to more permenent
storage.
Well, any server that plans to handle thousands of users ought to be written that way, since it sounds as though the current approach doesn't scale well at all. Then you wouldn't need to use a special transport for things like this.
Why not have the server use an external SQL database for storage? That way small installations that want to use free/open software can plug in mySQL, while large portals can use Oracle or Sybase or whatever.
�Jens
