Title: Journal for Wednesday, 4th May, 2016
Abstract: Wittering on about accounts and networking
    Tags: network, errors, accounts

                     JOURNAL FOR WEDNESDAY 4TH MAY, 2016
______________________________________________________________________________

SUBJECT: Wittering on about accounts and networking
   DATE: Wed  4 May 23:17:23 BST 2016

Monday was a bank holiday. Three day weekend to get some coding done. Or not,
as is more typically the case. I've been trying to write a journal entry for
the last few days as well. So although today is "WolfMUD Wednesday" - the one
evening a week I set aside deliberately just to work on WolfMUD - I thought
I'd write an entry before writing any code.

I've been working on the account logins still. I have a front end that can ask
for your character's name and then put you into the world so that you can
play. At the moment it's a bit of an ugly hack that I'm trying to improve on.

Usually when I ramble on about a problem, like I'm going to now, it helps me a
lot. Writing out the problem and issues really makes you think about things.
To quote Einstein "If you can't explain it simply, you don't understand it
well enough". So thanks in advance for being a sounding board :)

The main issue I've been trying to solve is how to cleanly - elegantly - exit
the game and close down the client's network connection.

The initial problem is one of a lack of separation. Player setup and insertion
into the world is done by the client network code. Until now this has been the
most convenient place for it. There is a main loop reading network data and
passing it to the parser. Inside the loop, after calling the parser, we have
to peek at the data to see if it was a QUIT command. If it was we tear down
the network connection - the QUIT command should have extracted the player
from the world before we peeked at the data.

Not an ideal situation.

The client network code should only deal with networking, network errors and
data I/O. It should not be concerned with handling players. It should not even
be concerned with what the data is - it shouldn't have to peek at the data.

The fix is quite simple. Add a front end driver. The driver then sits between
the networking and a processor/parser. Where the processor/parser can be
anything: the game, a menu system, account creation or even a chat system.

But. What is the best way to tell the networking code to exit? We could pass a
channel to the driver which can be used for signalling. Do we really want
another channel per player when we can, theoretically, have thousands of
players at once?

We already have an error channel per player. We also have a 'QuittingError' in
the networking code. We could return that error from the driver when we want
to quit. Although QuittingError is a terrible name - quitting isn't really an
error. As the main loop checks for errors each iteration and terminates if one
is found quitting, by raising a QuittingError, was simple at the time didn't
need any additional checking. Now though, if we treat the front end driver as
an io.ReadWriter we could return an io.EOF error when there will be no more
data returned - because we want to quit.

That makes sense and it's clean and elegant. Thanks for 'listening' to me
witter on, you've been a great help. I'm now off to rewrite some code :)

--
Diddymus