Open nslottow opened 12 years ago
Naming issues aside, the class is isolated largely s.t. the client is unaware whether the ServerConnection object is over SSL or not. In my mind's eye, the client stands the potential to get [much] more complicated if there are multiple game types, or if a player has multiple different bots, etc. Perhaps he'll want several server connections, perhaps he'll want to connect some instances of bots to different game servers.
Names are an issue, they'll shake out over time and are easy to change.
Exactly. So a server connection could be in the clear, it could be over SSL, we could build one of unix sockets, or even named pipes if someday we decide that we want really fast local gameplay.
It is an abstraction for when a client wants to connect to a "server" to play a game.
Another "server" could be an instance of another bot that just trades moves with you, then no actual connection is needed, but some translation is. The point is, to play a game a bot needs to join that game and get messages from that game.
On Thu, Sep 13, 2012 at 12:56 AM, nslottow notifications@github.com wrote:
The thing is, the ServerConnection is not even the implementation of the SSL or Clear client. It's just an abstract implementation of how to work with a Connection.
— Reply to this email directly or view it on GitHubhttps://github.com/ewust/blokus/issues/9#issuecomment-8518294.
Pat Pannuto Computer Engineering University of Michigan 248.990.4548
It seems to me that the client/comm.py module is really the main functionality of the client.py module. Is there a good reason the two shouldn't be one and the same? Nothing else will ever use "ServerConnection," and ServerConnection implements the same methods as "Client." Even if we decide to keep the ServerConnection class, it seems that it should be in the client.py module at least. The name is also confusing because there's a common/communication.py module. Thoughts?