(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 ;).
Mid-term report
Time to take a brief pause and take a look at the progress so far, and especially the road ahead.
What has been done
- Documentation - partial doxymentation has been done. However in the core functionality classes I decided to postpone this step for later - functions disappear and change functionality, so things aren't yet stable enough.
- Code style - reformatting of whitespace is done on a file-worked-on basis. Renaming of variables to more readable is done where needed. Some whitespace is also added for added readability.
- Typedefing - all built-in type STL containers (e.g. set of uint32_t) are now typedefed. FrameType and other enums are used where applicable, connection status is an enum. Some of the other containers are also typedefed, some are still left - usually in places where another refactoring is planned.
- Code cleanup - a lot of unused/unneccessary code was removed. A *lot* of duplicate code was moved into common places (mysqlpersistence lost almost 100kb of code!)
- Baseclassing - a hierarchy of basic base classes has been introduced and intergated almost everywhere where applicable : Identifiable, Nameable, Describable, Modifiable, Packable. Two fully traited classes have been introduced : ProtocolObject and ProtocolView. Integration has allowed removal of a lot of copy-paste code, and the possibility of starting refactoring using basic class traits.
- Network code - there was a big mess in the connection classes. I changed the inheritance tree what allowed a huge removal of duplicate code between the same functionalities.
- Messages - message and message board code was highly rewritten, moved to shared pointers and reorganized
- Exception handling - started work on using exceptions instead of error codes, created two base exception classes. More work to be done.
- Frame handling - frame's can pack now complex structures themselves.
- *View refactoring - ProtocolView base class, and major PlayerView refactoring done.
- STL usage - in many places correct STL usage has been introduced.
What hasn't been done and why
- Modularization - I was explicitly asked not to rename and move files, however, in the last weeks I'll post a suggestion of reorganization/modularization to the developer list to be put under discussion.
- ASIO - lack of time.
- Several unfinished items from the list above
Generally once I took a serious dive into the code, it turned out that there are a lot of places in the code that could use a cleanup. I'd rather invest time to do that properly and orderly than rush ASIO in.
What will be done next
I allow myself the liberty of throwing ASIO out of the first half of the project, and restructuring the plan to the fact that Phase 1 takes a whole half of the project. With this revised plan, I am of course still a little behind schedule because of the unfinished things in Phase 1. I consider that as a list of things to be invested with additional time. That leaves us with Phase 2, Phase 3 and Phase 4 for the rest of the project. I'd like to receive feedback as of what should be the priorities here, as I won't be able to push in all three phases into the rest of the program, at least in the GSoC timeline.
Current initial plan is to finish up Phase 1, move to Phase 3 (with a priority on shared pointer transition) then moving back to implementation of Phase 2. If time is left (what I doubt) I'll move to elements of Phase 4.
Modifiable
Somethimes it's hard to do several things at once. However, today I couldn't resist. While baseclassing was planned from the beginning it was meant to be done at a later date. Today however, I noticed that a lot of classes have the same modification time mechanism... perfect victim of baseclassing.
If only "Identifiable" would be so easy to integrate...
Connected again!
While today started with Exceptions, that I decided that are badly needed in tpserver, focus shifted quite away from that. I did implement a general SystemException class (and a deriving TlsException class), but the eye of the refactorer beheld another target -- the connection classes hierarchy.
Needless to say there were two exact copies of Tcp based connections, now there is one. I guess I removed a huge amount of code today -- now at least we have one Tcp path for admin and player connections.
As a sideeffect I stumbled across PlayerAgent. Addition of a few helper classes resulted in a 500 line removal of code (sic!).
Why do I have the strange feeling that when I end with tpserver it'll be like 3 times smaller? ;)
Player connected
Much work has been done since the last post. However current ramblings come mainly from todays work.
Error handling -- there's a big need for a better error handling mechanism. Currently the server suffers from spaggethi-like if-then-else mazes that make much of the code very unreadable. A sane implementation of exceptions is badly needed! Added to TODO list...
Memory handling -- while refactoring PlayerConnection I noticed that most of the frames created and sent are never deleted! I can imagine that memory leaks in the server must rise to absurd values if running longer than a few active hours. However I won't touch this now -- it'll fix itself when I move to shared pointers anyway.
:: Next >>