Re: [Rails-devel] Starting on a client/server

[brett l. <wak...@gm...>]

On Mon, Nov 3, 2008 at 2:41 AM, Erik Vos <eri...@hc...> wrote:
>> Just a quick update...
>>
>> I'm still working on getting the client/server parts working.
>>
>> Currently, I've gotten the startup code refactored, and am just
>> starting to tie it into the network bits.  Unfortunately, the fall
>> tends to be a busy time for me, so I haven't had as much time work on
>> this as I'd have liked.
>>
>> I'm not quite ready to push this back into cvs yet. I'd like to get a
>> bit further into having a minimally functional client/server. Being
>> that this is an open source project, perhaps I shouldn't "go dark" for
>> too much longer. I've been using github.com to push my changes between
>> home and work, so that I can work in both places whenever I have a
>> free moment. (Note: this doesn't mean we're changing revision control
>> systems. This is just my personal place to store code. When I feel
>> it's ready, I'll push this code back into cvs.)
>
> Perhaps you should create a new branch in CVS for it?
>

Once it's in CVS, it can't be deleted. I don't want to check it into
CVS only to scrap it entirely or need to completely redesign it.

I'd prefer to keep our CVS tree populated with active code, rather
than my random ideas. ;-)

>> So, you're welcome to check the current state of things here:
>> http://github.com/wakko666/18xx/tree/master
>
> I have downloaded it and tried to run client and server, but
> 1. The compiler reports an error in the client:
> The method actionPerformed(ActionEvent) of type NetworkClientWindow must
> override a superclass method    net/sourceforge/rails/client/ui
> NetworkClientWindow.java        line 77 1225706052046   65163

Hmm...  I'll have to double-check that all of my changes were merged
with the last push. For now, removing the @override decorator should
remove the issue.

> 2. I can't find a Server main method.
>

There is no server main method. Right now, when you hit the "new game"
button, it launches both server and client (which currently don't do
much of anything).  I haven't yet added in the interface for starting
a standalone server. I haven't quite decided what that interface will
look like. I'm debating either a command-line interface, or adding a
button onto the client start-up interface.

>> There's some fairly major reorganization that I've done, and I've
>> totally refactored the XML parsing.
>
> Can you elaborate a bit on how you see XML parsing be done your way,
> and what the perceived benefits are? What exactly was wrong with it?
>
> It strikes me that the XMLParser API has the dreaded Document, Element and
> NodeList
> types that I have so carefully hidden inside Tag last year...
> Will XMLParser replace Tag, or will the former just be used by the latter?
> In any case, GameInfoParser isn't using Tag.

Correct. There's nothing wrong with abstracting away the details of
the XML DOM, per se. Tag does a fine job of that.

I don't think our current method is doing anything wrong. Mainly, I
wanted to see what it looked like to collect all of the
configureFromXML methods into one single parser structure.

The one benefit that this different method adds, is that we don't have
to wait until we initialize a specific game object in order to parse
the XML for that object. This provides access to that information to
things outside of that specific game object. This will avoid similar
issues like we had adding in variants and game options.

At this point, I would consider this experimenting with a different
method for code organization. I'm happy to scrap it to retain the
existing methods if it doesn't provide any real benefits, or has some
obvious problems.

> Will your reorganisation extend to replacing/rewriting the configureFromXML
> methods of so many classes? Please be careful to retain the
> dynamic extensibility of the XML that we have gained by having
> (possibly game-specific) classes parse their own dedicated XML.

Yes, this was the key thing I wanted to try in a slightly different
way. What I'm looking at is splitting the game classes into two parts:
the game model class, and the xml parser class. The configureFromXML
method would be refactored into its own class, so that the game model
class is only concerned with manipulating existing java objects.

As for extensibility, that hasn't changed. The only real difference is
that all of the XML code is moved to their own classes, rather than
living in the game classes.

>> Both of these I'd like to see
>> comments on before I push this into our code repository. Things are
>> still in heavy flux, so none of this is set, and I really don't want
>> to shake things up too much without make sure you guys are also happy
>> with it.  My hope is that some of these changes will help make
>> reorganizing the game engine code a little easier.
>
> Before I can judge all this I would like to know what your thoughts are
> on the direction in which the game engine need be "reorganized".
> What are your sore points?
> Of course there is much work to do in the existing code to make the
> client/server
> split possible at all, but so far I cannot see much of that in what you have
> published,
> and you seem to stir up quite a bit more than just that.
>

Well, I don't know of any specific things in the game engine that need
reorganizing. I know that when we talked about this last, you
mentioned that you had wanted to take a different approach on some
things.

Most of what I've currently done is just refactor the initialization
code to allow it to start a client and a server. I've also streamlined
initialization a bit. For example, there's no longer a
games.properties file required to figure out what games are available.
That information is loaded directly from the GamesList.xml.

> In general it is not very clear to me what direction you are taking,
> and why, on matters that are not immediately related to the client/server
> split (such as XML parsing).
>

I suspected.  When I started this, I just started working from the
beginning of the app's initialization. There have been some things I
wanted to try doing with the start-up code as I was making it aware of
needing to start a client and server.

I can see how it's unclear, as there's not much of the client and
server bits to show off yet. it's still mostly the start-up code with
some minor tweaks, a new parser, and a radically different package
layout.

My main concern is that I've spent a few weeks on it without showing
it to anyone, and I don't think that's the right way to do an open
source project. I really don't want to just dump a major code change
into CVS without having some conversations about whether I'm doing
things in a way that everyone is reasonably happy with.

> Erik.
>
>

---Brett.