Re: [Antbear-devel] Summary Doc, Update to Class Diagram, Connection States.

[wolpers]

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