[FreeCiv-Java] Re: FreeCiv-Java proposal

[John Goerzen <jgoerzen@xxxxxxxxxxxx>]

Esben Haabendal Soerensen <ehs@xxxxxxxxxxxxxx> writes:

> > least) two threads implicitly: the GUI thread and the thread for
> > everything else.  It has this without you creating any thread.
> 
> The word I focus on most in the above is "implicitly".  The most
> efficient way to make code harder to understand is to do to much
> implicit.  This is true on the syntax level (I love making Perl code
> imposible for other to read :-) ) but even more true on the design
> level.  The more of the concepts of the design that are made in an
> explicit way the more easier the complete design is to grasp.

You're looking at this from a bit of a different perspective than I
am.  I do come from different programming languages where you have to
worry about these things.

The Java Way is that you don't worry about the GUI.  You tell it to do 
something and it does it.  It automatically is around to wait for
actions from the user, repaint things, etc.  (This is even more true
in JFC/Swing).  It happens to use a thread to accomplish this, but
adding an additional thread for everything non-GUI will only add
complexity.

> And we seem to generally agree about how working of the design
> have to be, we just need to decide how to actually do it.

Yes.

> Take the network listener thread I have mentioned.  It is of-course
> true that in your current code there is a thread dedicated for
> that, namely the thread that started the main() method and
> settles in the while(true) loop.  I would prefer to let the main()
> method initiate any nescesary Thread classes and then finish.
> I prefer to think of the main() method as a bootstrap method.

There's no real problem moving the while() loop elsewhere.  There's
no terribly good reason one way or the other regarding whether or not
main() should be allowed to exit before the program does.  In some of
my programs, it does; in others, it doesn't.

> only do network stuff.  When dealing with packets this "network stuff"
> means listening for packets, receiving packets (making them into
> some Packet object) and passing this onto some dispatcher, and
> of-course accepting Packet objects to send to the server.

This is just fine.

> The important idea in the above is that the dispatcher is more
> game related than network related.  I would prefer to seperate the
> tidious code with selecting which classes should receive which types
> of Packet objects from the code actually receiving the Packets.

This is reasonable, and in fact the current design does indeed make me 
somewhat nervous for that reason, but I didn't have a better idea :-)

[chomping]

> I would like to see the gui code ONLY handling the following two
> types of tasks:
>   * create all the frames, buttons and that stuff (and by doing this
>     they also setup all the callback stuff handling the user commands).
>   * updating the gui when nesecary (like moving enemy units)

Sounds fine.

> > (ie, the client receives a packet from the server saying what the
> > timeout is, and then displays a counter and keeps it updated itself)
> 
> Ahh, now I see what you mean.  I need to get one thing clear (having
> no experience in the freeciv code):  Does the server send a packet
> when the timeout period has run out ?

No.  The only thing the server ever does with the timeout is inform
the client when the timeout changes (when the server-op sets it to a
different value, not each second).  Hence my assertion that the
timeout is basically a GUI-only thing; only one packet is received and 
nothing more for potentially hundreds of turns.

> Let's do some coding!! :-)

OK!

> And what about this:
>   Make a freeciv java-server and a freeciv applet-client !

A java server would certainly be interesting, but not something I have 
a particular interest in at this time.  (Perhaps after a java-client
is working though...)

>   Then when you start the java-server anyone with a browser
>   can play :-))

It actually won't be hard to make a Java client runnable in a browser, 
once browsers appear that support JDK1.2.  Otherwise, we have to ship
the swing.jar file along with the rest of the program, and that's not
pleasant (swing.jar is huge).

> > I'm not quite following.  If there is a chat window, it's not directly 
> > between clients, but between one client and the server (the server
> > passes on the mssage).
> 
> True as it is now.  But wouldn't it be cool to be able to open a
> chat window with only selected players being able to see the messages ?
> It would make it to have aliances with more than two players.

Yes.  This code already exists in freeciv, just not with a separate
window.  More like /msg in IRC.

> > An AI is no different than a normal client.
> 
> Well.  In the end there is a big difference.  It would be stupid
> to talk to an AI, and it would therefore not make any sense to
> open a chat window to any AI players

Not necessarily.  Remember that it is possible for there to be a
client connected to an AI player, and a live human at that client.
The human wouldn't have much control over what happens, since the AI
does all his work at the start of the turn.  However, people often do
this to learn and watch the AI, or to just be part of the game and be
able to chat with others.

A conventional AI has no corresponding client connection, and so looks 
to other clients just like a normal connectionless player, and we can
assume that it accepts no messages.

> True.  But my point is that en an abstract way there is a big difference
> between AI and human players.  When I play I handle AI players and human

On the server, perhaps, but not even much there.  The main difference
is that if the player is an AI, at the start of a turn, the server
calls a function that makes the moves for the AI player.  That's about 
it.

> humans the discussion should be if we should make the distinction by
> using two different classes (with a common superclass) or just use an
> attribute in the Player class.

An attribute is fine.

> I would go for the first, as this would make it possible (and easy) to
> add methods to the human Player class that makes no sense for an AI
> controlled player (such as opening a player specific chat window).

But as I've said, it can make sense :-)

> But changing the way the threads should not make much difference
> regarding to speed.  By making a network specific thread instead
> of just using the main() thread would not make any difference in
> speed, but would IMHO improve the clarity of the design.

I have nothing against moving code out of main() into somewhere else.
Perhaps it would be possible to do this now, and if it becomes
necessary to add threads later, they can be added then?

> In the end there will probably only be one realy sensible way to
> do this thread thing.  I can not foresee if we are going to do this
> different at some point, but at the moment we seem to agree on
>  * a thread to handle the network listening (be it main() or some other)
>  * a thread for handling the gui (the internal swing threads...)
> 
> But I would prefer to add one more.
>  * a gui update thread
> 
> This could be done just by letting the network listening thread call
> some method which then does this.  But this would change the task of
> the network thread to also handle all the gui updating.  Although
> I aggree that the scheduling of Java (at least with green_threads) is
> extremely poor, why not make a design where the network thread just
> passes the messages (packets) on, and then lets a dedicated gui update
> thread handle all the updating of the threads.  This seems to me
> to be the right thing to do.

This won't help things much, because most if not all packets must be
processed in sequential order; processing them out of order doesn't
help.

> And if we can make this multie-threaded design work the result can
> be much more effective than the other basically single-threaded
> design (ignoreing the internal gui thread).

I would say to not add extra threads now, but with a good design as
you've put forth, it should not be difficult to do so later.


> 
> No wait.  Are you going to make a freeciv-java list ?  I would like
> this.  Even if we are only two the mail-archive would be great :-)

OK, I made one.  freeciv-java@xxxxxxxxxxx (aka
freeciv-java@xxxxxxxxxxxx of course).  It'll have an archive in a few
minutes.  I am not announcing this publicly for a few days (to the
other freeciv lists anyway).  I shall make a public announcement in
due time.

subscribe, of course, is done by writing to majordomo@xxxxxxxxxxx and
in the body type "subscribe freeciv-java".

John

-- 
John Goerzen   Linux, Unix consulting & programming   jgoerzen@xxxxxxxxxxxx |
Developer, Debian GNU/Linux (Free powerful OS upgrade)       www.debian.org |
----------------------------------------------------------------------------+
Visit the Air Capital Linux Users Group on the web at http://www.aclug.org