(Not so) final report

Time flies fast when you're having fun. GSoC is over, and I'm not finished -- that's a fact. But I'm not willing to finish -- that's another.

I didn't fully realize the sheer amount of work that the server needed. Let's face it -- there were many parts in it's code that were ages old. I am quite proud that this is not the case with the code currently in the refactor branch.

The ideas I suggested in the proposal are still valid, and I'm still sure that they are going to greatly benefit TP in general, however, during the few months of GSoC I understood that my main assignment was to bring the code base up to a nowday standard. In terms of my original goals, I admin -- I failed. But in terms of sheer changes, lines of code touched, and improvements made, I feel that I did a big amount of good work.

What has been done?

The most important work done is making the code "contemporary". Typedefs are used where applicable, the code uses STL to it's full power (powered up by a custom algorithms collection), all pointers are managed with shared_ptr and weak_ptr classes. Interfaces have been streamlined, many of the changes were directly injected into the 5 existing rulesets. Most important of all, hundreds of duplicate lines of code were removed, and the structure of the server was made more concise. Almost all Protocol-related classes now are descendants of a common ProtocolObject base class that handles many tasks on it's own. I also worked hard on grouping logical actions together, for example to handle frame processing only in distinct places -- this however needs more work. Also, see the midterm report, it handles some of the above changes in more detail.

What needs to be done?

There are a couple of things unfinished -- Order's are still passed via normal (non-shared) pointers, and there are a couple of standalone pointers dangling around. This wont take much time and will be done as soon as I come back from vacations.

Documentation is missing -- yeah, I promised that I'll do that, but seeing the amount and scale of changes that I needed to do, I decided that documenting the classes should wait until the server more or less stabilizes.

Compilation of optional parts -- some of the optional enhancements like avahi or mzscheme do not compile and weren't tested at all -- pushing them up to compilation state shouldn't take long, testing will take longer.

But most of all -- TESTING -- I'm pretty sure there are bugs in the server as it is now, probably plenty of them. Especially at the last weeks I kinda pushed testing away to at least accomplish the basic tasks of my original proposal. However, I fully commit myself to getting the stability needed to make the refactor branch the new head.

What is planned further?

Ideas from the original proposal are still valid, out of them I would especially like to implement ASIO, as I really want to learn it better. However as I see now, if ASIO would be the goal, it'd have to be a separate GSoC project, and considering the state that I saw the server in at the start it'd probably be a hack-fest in itself. Not to mention that the resulting implementation would be buggy as hell because the server is completely not ready for threading.

More integration of common code is also possible -- one of them is the barely started Manager base class, and ID list frame processing. However here there are a few more ideas that I'd love to do.

Most of the tasks in the bug tracker seem now trivial to do, I'll address them also (hey, I do wanna get that TP T-Shirt, and preferably another one for my girlfriend, because she likes the design ;>).

What would be really cool?

I'd like to see 0.5 of the protocol updated design that would allow for easier integration of common code -- separation of frames into classes that could be handled by the same processing code. However that's a very far wish-list, and wouldn't do much good if the server were to support legacy protocols (why do we need that anyway? There are not much games in progress now, are they?).

I'd also like to see most of the ruleset data stored in XML files. As for now, there is way too much code that just sets up strings in the code. On a further note, why not add lua support to the level that would allow creating a ruleset just with lua and XML?

Summary

It seems I'd like to be a TP-developer, at least until the server is up to date. Maybe I won't be able to commit as much time as you guys, but damn I'd like to see this server being top class ;).