Merge lp://staging/~widelands-dev/widelands-metaserver/ircbridge into lp://staging/widelands-metaserver

Nice. That is a really good idea and I think the implementation looks reasonable too. It is a bit drafty still, though (see comments below). Was this the first time you did something with go? How did you like it?

Some comments:

- func NewIRCBridge() IRCBridge should read its configuration from the same json file where we read the data from right now too (see main.go).
- I think the design is a little fragile - if something goes wrong with the IRC connection the whole metaserver comes down. How about running the IRC bridge in a go routine that gets a (buffered) channel of stuff to send and also sends stuff into a channel that the metaserver then displays? That way if the bridge is disconnected it can just discard the messages and the whole design is a bit decoupled. Also you can fake some IRC messages in a test and test the whole thing.
- +func (s *Server) Motd() string - I do not agree with this change. When a method is not changing a struct, it should not be a pointer receiver. There are only a few exceptions to this rule as far as I understood go so far (not an expert by any means).
- Please add some tests. Feel free to add end to end tests, there are already a few in the metaserver.

Thanks for the comments, of course i only wanted a review, not a merge in the current state.
This are my first steps with go, so i am just glad that it works at all ;).

- i will add tests
- the irc library handles disconnects itself, and because of the use of a callback function for irc->lobby it is already decoupled. I disconnected from the internet to test and it automatically reconnected and the lobby was still usable. But i will look into using a routine and buffers...
- pointer recievers:
Here i am really unsure, but i've found:

   A method is a function with an implicit first argument, called a receiver.

   So when you call a method:

   - if the receiver is a pointer to int, it copies the pointer to int.
   - if the receiver is a struct, it copies the struct.
   - if the receiver is a pointer to struct, it copies the pointer to struct.

So even if i don't want to modify the struct i would think avoiding a copy operation by passing a pointer to the struct should be faster? But here speaks only 1 day go experience... ;)

> But i will look into using a routine and buffers...

I understand your comment, but I still think it is a good idea. First, because it is more idiomatic go (as far as I see it right now :)) and secondly goroutines and channels are essential building blocks that somehow set the language apart - you'll find them really interesting I think.

> So even if i don't want to modify the struct i would think avoiding a copy operation by passing a pointer to the struct should be faster?

While this is correct, go optimizes these very strongly. Sofar not using a pointer has not been a performance bottleneck in go code for me. And not using a pointer signifies to the programmer that the method will not change the receiver - which is nice documentation. So only use a pointer receiver when you need to (i.e. when you need to modify the receiver) or when you measured that it impacts performance by benchmarking.

Ok, channels are in place.
Next up are tests, but first i need to understand go tests. The current tests starts dozens of server instances in a few seconds, i need to use only one irc bridge instance for all tests or have to implement my own tests with active irc bridge.

I do not fully understand your question.

If you only want to test the behavior of the server you can just hand in two channels and fake messages on those in your server tests (i.e. no IRC Bridge is created at all). I think this is the most reasonable approach to take since you cannot rely on IRC being up when you want to test your scripts.

You can also choose not to test your new implementations, but you must at least change the setup procedure so that not necessarily an IRC connection is made when a server is created.

And progress on this? Anything I can help you with? If you are stuck we can also remote pair on the code for a bit, maybe we come up with something together.

The current state is:
- it is working, communication between ircbridge and metaserver via nonblocking channels
- tests are working, result ok
- no tests regarding the ircbridge itself or communication implemented

I am a bit busy atm, i think i won't have time to implement further test before next week.

no pressure - just wondered if you still want to work on this or if it should be merged around now.

Ok, perhaps we can merge now?
I does work(tm), only the testcase i've drafted seems to do nothing?

looks good to me. I merged and deployed on the server - thanks for your work on this!