-
Notifications
You must be signed in to change notification settings - Fork 88
New object model
There are three classes of things sent to us from the server that interact between each other - games, players and IRC users. By isolating the logic of adding, removing and updating them away from widgets we'll make our life much easier.
Players represent registered FAF accounts. A list of players is sent to us from the server, then we receive updates on players joining and leaving. Every player has a unique, immutable id and a unique, mutable name.
Games represent live lobbies and live games. A list of games is sent to us from the server, then the server sends us updates regarding games. A game might be in one of free states: OPEN, PLAYING, and FINISHED. A game holds a list of teams of players, identified by their names. These teams can be updated. Every game has a unique, immutable id. A game does not change its players when PLAYING or FINISHED.
IRC users are sent to us from the IRC server - and appropriately updated, added and removed. IRC users have names, and some IRC users correspond to Players - same name indicates correspondence.
Games and Players are in a one-to-many relation. Each game has at least one player, each player participates in at most one game. We should handle situations where a game refers to a nonexistent player (or player to a nonexistent game) gracefully. In particular making the relation indirectly through player name and game id is preferred.
I don't think the server notifies us about everything (in particular it might fail to notify us about players leaving a PLAYING game), but the following are certainly axioms:
- If a live game has its players updated, all new player names should be in relation with this game, and all old player names that were in relation with the game and are not on the new list should be in relation with no game.
- Above rules also apply if we are sent a new game.
- If a game is marked as finished, all its player names that were in relation with this game should be in relation with no game.
- If a player connects, he should be in relation with ID of the only game that is in relation with his name, or with no game ID otherwise.
- If a player disconnects and is in relation with a game ID, that game should still be in relation with his name.
This relation is more simple - a player and an IRC user correspond when they have matching names. Therefore the only thing we need to do is check for another player / IRC user when adding / removing / updating players or IRC users.
- Player, Game and IRC User each have a corresponding class.
- Three singular objects of classes GameSet, PlayerSet and IRCUserSet that keep track of new and removed objects, allow to look them up by their identifiers, and notify about some updates that consumers might be interested in (so they might start tracking a given object).
- Two objects that track relations - GamePlayerRelation and PlayerIRCUserRelation. You can give them identifiers of one object and get objects they're in relation with.
- Objects have references to their sets, sets have references to their relations.
- Object is updated, changes its internal stuff, calls the set to update its stuff.
- Set updates its stuff, calls relation to update its stuff.
- Relation updates its stuff. Now things are consistent.
- Relation emit relation change signals.
- Object set emits 'new object' signals.
- Object emits its update signals.
The only code that modifies objects is not connected to any signals emitted by the above system, to ensure we don't get any loops. Since the code in question only listens on the connection to read and update data, there should be no need for this.