[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Antbear-devel] Summary Doc, Update to Class Diagram, Connection Sta
From: |
wolpers |
Subject: |
Re: [Antbear-devel] Summary Doc, Update to Class Diagram, Connection States. |
Date: |
26 Nov 2002 00:55:13 +0100 |
On Mon, 2002-11-25 at 23:32, Daniel Ng wrote:
> Hi guys,
>
> Adam, thanks for doing the html file- we definitely
> needed that to keep track of our decisions.
Japp, good one.
>
> I realised there are some mistakes in the Class
> Diagram, in particular- the Gameserver and Supporter
> classes are missing, and these should each be
> associated with exactly 1 connection. Also, the idea
> of a connection database is wrong. It should be a
> Gameserver database, and a Supporter Database instead.
> I will update the diagram then we can see if we
> agree...
Yes, I do like that better.
>
> Adam, with the Threads part of the html docco, I think
> we agreed on a GUI thread and a "GUI-dealer" thread
> ie. 2 threads for the GUI. The GUI thread makes sure
> the GUI is always refreshed eg. if the window is
> moved. The "GUI-dealer" (what I referred to as 'GUI2'
> in the mailing list) takes care of the action
> requested via the GUI eg. disconnecting a Supporter.
> If we all agree on this, I can update it...
Yes, but do we need to mention the GUI (refreshing) thread? This thread
is nothing we explicitly declare as beeing a thread. This is
automatically done by the GUI-toolkit(AWT):
(1) A button is pushed and then (2) the
connectedActionListener.actionPerformed(ActionEvent action) method is
launched. Once that method is completed (3) the GUI will be repainted.
So we need to place methods that could possibly work a second or more
within a separate thread that is launched from within that
actionPerformed() method without blocking.
To point that out I thought it might be enough to add 'apart from the
Event-Handling GUI thread' in parentheses to the thread Amang mentioned
on the html document (unless that would be no good practise).
>
> Another separate issue- what do we do about the State
> of a connection? For now, I am proposing to have a
> single set of States that all connections can be in,
> whether they are connections between Master+Client,
> Master+Supporter, etc.
>
> So, these states will be quite general eg. Sent List,
> Received List, Sent Ack, Received Ack, etc. Later on,
> we could have states like 'Authenticated' or 'Awaiting
> Authentication'. I think this would be okay for the
> current class diagram (the above changes to the
> diagram won't affect this), because we have a separate
> class per connection type, so we can later have a
> separate State type for each connection type eg.
> ConnToGameServerState vs. ConnToGameClientState.
Sounds good to me.
- Thorsten