[Freeciv-Dev] Re: Windows COM client

["Arlo Belshee" <arlo.belshee@xxxxxxxxxxxxxx>]

> Using COM/DCOM is a terrible idea in case you want Freeciv to retain
> portability.  It's much less portable than CORBA for e.g.

Note that I only used the COM name in the subject. Actually, I agree with
you on this. I used COM in the title mostly to sufficiently overstate my
position that I evoked a response and got people thinking in the component
direction. My main focus is really this "can we break this stuff up into a
set of seperate components". Better yet would be for these components to
take advantage of encapsulation, to be rather independent, and even better
would be for those components to be linked together at runtime (so that we
could swap generic algorithms with specialized ones, depending on runtime
capabilities).

The goal is to break the project down to increase flexibility and
accessability - the same arguments as are generally used for an object based
design or architecture. Anything which decreases portability decreases
flexibility, and is not allowed. With more segments, however, people can
work on specific areas and port them to take advantage of platform
capabilities or match 'standard' platform look-and-feel.

> IMHO you have some freedom in how you can program the client bit but
> changing the whole sourcecode to use Windows specific stuff is evil (TM).

I agree with you on this one: portability is key. I am thinking of creating
a structure that operates in a similar fashion to COM, but is far more
barebones. It doesn't do registry magic, and isn't designed to work with
anything outside this project or this group of developers. It depends on
some central information store that we would create and define (stating what
components there are and where they can be found), which is not expected to
contain information outside of the FreeCiv project.

> Then i got one free week without anything to do:  i looked at the source
> for 3 days and found it wasn't that hard to understand.  I was just
> looking at the wrong places.  The source filenames mostly give you an
> indication of what they are used for, the code is readable - even if
> sparsely commented, and things are usually well split up and reused.

I believe you on this, and I am at the point where I haven't had a week to
look through the code and break it down, so anything I say is suspect.
However, I bring the following points:

1. I am never going to have that week, and neither are a bunch of other
people.
2. I don't care about most of the code base and don't want to deal with most
of it.
3. Within areas that I care about, any change I make will propogate (I
think).

Further explaination:

1: I work at a startup. I look for something interesting to do on the
weekends and occasional weekend. I have between 20 and 40 hours a week that
I'd like to dump into something like this, because it's relaxing. However,
it is intermittent, unpredictable, and never in consistent chunks. While I
can remember what I was working on from time to time on that schedule, there
is no way that I can remember from time to time what I was learning and what
I'd figured out. This means that while I could work a lot on the project, I
can't get started. I doubt I'm alone on this: I expect there are a bunch of
domain experts with 5 spare hours a week (but no more) who could offer a lot
to the project, but have no way to get in.

2: There are several segments of code that I have no interest in figuring
out or reconstructing. In my first project, especially, I wanted to make a
change to one well-defined and small area of the project: the AI. However,
in order to start to understand the AI or to make changes to it, I really
needed to understand the entire code-base: it tied into everything. If we
have well-defined internal interfaces (boundaries), then an individual
developer needs only to understand everything out to those interfaces, and
understand how the interface works. I would be able to pull out the AI,
produce some new thinking mechanism, and plug it in. With runtime linking, I
wouldn't even have to recompile anything: build my AI, tell it to link to
this one instead of the old one, and away I go. I don't need to figure out
how to display a map.

3: It is very difficult to tell what changes will propogate through the
system. Again, I do not understand the way that the entire system works.
There are clearly a lot of links: the whole thing is very highly coupled.
This means that when I want to change something, I can readily determine
that there are a large number of things that this might break, but I don't
know them all. This makes testing difficult even if I know the system, and
it leads to paralysis if I don't. Fundamentally, this is the primary
weakness with the code base; this is the thing that several people have been
thinking about when they posted messages stating that the code base was
difficult to understand, ugly, messy or whatever. The code can't really be
subdivided, either on an architecture level or a code level. After you
understand how everything works, you can start to segment it and break it
into pieces: you have internalized the system and its interactions. New
users don't have that, but can quickly get up to speed if those breaks occur
naturally in the code (especially if each piece can be built seperately).

> If you really want to know what i did when i started the gtk+ client port:
...
> After porting the main map, and afterwards the city window, it's a
> question of patience to port the other dialogs.  I suggest porting the
> city list dialog (the one when you press F1) and the help dialog/menu
> system next.

Yeah, I could go through and do much of this. It would take me a bloody long
time, given the hours that I can dedicate. And if I _do_ do it, I want to
make _damned_ sure that I'm the last person who ever has to. Liberal
application of components (even as static-link libraries), STL, and object
wrapping would help define and simplify the chunks in the code. I believe
you when you say that the current code has good reuse and segmentation, but
I currently have to take it on faith, as I can't afford to take the time to
figure out where it is.

Arlo