discuss the merits of having the bot be polyserver as well as the implications therein

[wraithan]

SEPoCoNi will be a good start. I'll toss notes in here.

[wraithan]

Polyserver looks pretty easy on the surface, but the problem comes when you have anything channel specific in your services. You then have to check both the server and the channel, as well as always sending back the server when you reply to something. External services also need to know what you call the server.

On the other hand it lets you run a single bot against multiple servers using one set of services and a single redis db. This may not outweigh the complexity overhead.

[hackervera]

I vote one bot per server, but have a system for controlling bot processes

[wraithan]

Well, for each bot process, I'd be instantiating it once per server and keeping it in a list. So they'd be separate sub processes, and manageable in that way.

[wraithan]

Closing this, going with one bot per server for now until there is demand for otherwise.

[wraithan]

Ok, going to add polyserver to the API, but not actually make the bot work with it. This may be slightly confusing but what it does is make it so you can run multiple instances of the bot that know what server they are running against, but only a single set of services. Also it means someone could make a polyserver bot that handles it all.