This is going to be a lot of round-trip calls when the bot first starts. I think this should be fixed (in a later PR), once we have networked varys somewhat working.

[llmII]

This is going to be a lot of round-trip calls when the bot first starts. I think this should be fixed (in a later PR), once we have networked varys somewhat working.

Originally posted by @qaisjp in #95 (comment)

See line in irc_connection.go

It's a tricky one to solve but would make good sense to do so. This would mean the bot needs to know when its starting, how many connections its issued, and wait for each connection to signal that they're connected (OnWelcome) and when the signal is counted to a certain number issue a varys call "GetAllNicks" or something.

[qaisjp]

The hope is that on initial varys connect, it does an initial sync of data.

and we will probably want to implement additional syncing for the nick too (thus essentially pulling nick tracking(?) or something out of the irc library, and into go-discord-irc)

[llmII]

Bridge connects to varys that never exited and still maintains xyz odd connections to IRC. Bridge has to ask varys "who do we got" and sync that up with what it sees on Discord. Then bridge has to process disconnects and connects. At this stage bridge doesn't need to know anything about nicks quite yet. After all connects are processed bridge then issues a "SyncIRCData" or something to varys. Varys kept up with all the data for nicks since the puppet connections told varys the relevant data. Basically bridge didn't have to have an onWelcome or similar at this point. That handles basically grouping data sync at startup. After startup it then can install actual onWelcome handlers to handle reconnects (hopefully those aren't so often as to generate a round-trip-flood). Somewhere in there it needs to detect a "mass-disconnect/reconnect" and of sorts say "pause, drop all onWelcome handlers" and figure out how many it needs to wait for connection on... and then issue the mass data sync call again? The only thing is in the latter case it could result in either double ups or if it's a true pause, it doesn't even push out messages until the mass data sync is done (meaning dropped messages?).

I'm trying to get a feel for the idea of it. Currently puppets don't install state tracking and I'd sort of hope they won't need it except to notify the IRCManager of certain things regarding I think the only real state we currently keep up with for puppets which is puppetNicks. I think the latter part I describe about mass disconnects would be hard to get right and doubly or droppy which would be worse than incurring tons of round trips (for the most part, there's a tradeoff probably around 100+ simultaneous network calls?).

Looking back at my original comment, on startup bridge could count "I have 10 connections" and see "5 discord users disappeared and I need to drop them out", process drops. Could see a "10 new discord users jumped in" and say "I must tell varys we want 10 more connects!". Then each client it creates (be it en masse or individually) gets an onWelcome handler that just says "add 1 to this variable with this function". The function could be something like "hmm, not 10 yet" then when it gets to 10 it says to the bridge "issue a varys mass sync". Then after mass sync it redoes the onWelcome handlers to actually play with puppetNicks. The issue here is... we still have the roundtrip call from varys signalling onWelcome up into the bridge I'd think?

The next idea is something like each GetNick call actually popping into a queue (and any state related call) and when that queue (per call type) is xyz deep in zyx time convert to mass sync calls?

Another idea is something like "state diff" where each side keeps a UUID for last state exchange and bridge says "state changes since $UUID" and varys says "these" but figuring out how to signal "massive state change" is difficult without each connection saying it connected. Unless a way to tell varys "wait for all these to Discord ID's to get connected, then notify us" maybe...