<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Sep 25, 2013, at 11:05 PM, Daniel Sank <<a href="mailto:sank.daniel@gmail.com">sank.daniel@gmail.com</a>> wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite"><span style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">This isn't THAT bad. The client's requestMove is thin and unecessary (I put it there for illustration). Still I need to have two separate classes with corresponding methods to handle moving the piece.</span></blockquote><div><br></div><div>That's OK. Don't try to reduce your number of classes just for the sake of having fewer classes. Each class should have a clearly defined responsibility. In this case, your responsibilities correspond directly to the things that have to happen on the server (validating the move) and the things that have to happen on the client (updating the graphical representation to correspond to the new game state). Having more, smaller classes means that it's easier for you to understand each class on its own, and programming is nothing if not the act of promoting local understanding :).</div><div><br></div><div>If anything, you should have an additional class to separate out your remote_* responders and the actual internal state.</div><br><blockquote type="cite"><span style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">This seems like the kind of thing I could twisted.pb to solve more cleanly if I only would look in the right place.</span><br style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote></div><div><br></div>I don't know if this is going to <i>directly</i> address any of your concerns, but have you considered using twisted.spread.flavors.Cacheable? That will atomically combine the propagation of initial state with the provision of the back-propagation channel for updates to that state. It's designed for exactly what you're doing, maintaining parallel simulated states on client and server.<br><div><br></div><div>Does that help at all?</div><div><br></div><div>-glyph</div></body></html>