On Sat, 21 Jul 2012 06:48:19 PM Paolo Bizzarri wrote: > I understand the question is silly, BUT, as I can see, we have two way > on interacting among client and server: > > - via serverAPI > > - via the FreeColServer object inside the FreeColClient. > > Why?
History. I only created ServerAPI quite recently, with the goals of: - Wrapping up the message passing so as to make changing from DOM based messages to pure StAX easier. - Perhaps one day being able to unify it with AIMessage (which might better be called AIServerAPI). > I think we should make use just of the ServerAPI, and stay happy with > that. Well, we could, although I am not convinced it is of huge benefit. We touched on something like this before, and IIRC I made the point that removing the freeColServer reference from the debug routines (see DebugMenu) was just too hard/wrong--- the debug routines really do need low level access to the server internals yet must live in the client, so a FreeColServer reference is always going to be needed. Please do not propose removing the debug routines after FreeCol is bug free:-). The other hard case is the reference inside the client InGameController.saveGame. I have tried unsuccessfully to have the server do the game saving in response to a message from the client, but hit all manner of nasty races, and deferred that untill after the DOM-switch. Now in both the above and the other cases that I forget, you could just hide the getFreeColServer() call inside ServerAPI. Is that sufficient for your purposes? Thinking about this a bit more, I begin to wonder if we have the structure of ServerAPI upside-down!?! All FreeColServer instances live inside FreeColServerHolders. Controller extends FreeColServerHolder. All our Pre/InGame controllers extend Controller. Currently we have the client InGameController calling out to a ServerAPI that hangs off the FreeColClient, with server comms routines in ServerAPI and higher-level game action handlers in client InGameController. This is what I think is upside-down. I should have kept the server comms routines inside InGameController and created something like UserInGameController (extends InGameController) to contain the game-level code. Something similar could be done with the the client PreGameController. This would also smooth the path to merging in the AI comms on the distant day when AIInGameController becomes an extension of the client InGameController. What do you think? Also, a few of comments on the recent changes: 1. Have you tested multiplayer? Single player is OK, but the ServerAPI changes go fairly deep and this is brittle code. 2. How confident are you that the Client instance in ServerAPI never gets used before it is set (in connect())? And/or after a disconnect but before reconnect? It looks like an NPE waiting to happen. I realize this has probably always been the case, but the changes make this much more visible. 3. I know I must be annoying you by always leaving unnecessary imports (it is unintentional, I would stop if the the compiler warnings I see showed them). OTOH, the Javadoc in ServerAPI is less than ideal:-). If you run "ant javadoc" you will see we are up to about 30 warnings, up from zero when I cleaned this up last (in April?). Note also that no warning is generated for a public routine with empty Javadoc, which IMHO is a mistake. This is a very low priority issue, and one where I am at fault too, but please keep it in mind. Cheers, Mike Pope
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Freecol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freecol-developers
