This Week:

This week's big accomplishment was completing the wizard. From initially getting it to work to a fully functional wizard only took two (long) days of hacking, thanks to good preparation everywhere else.

I also improved the control scripts and XML definitions. The server and ruleset stuff implemented so far works well.

Big sigh of relief. Looks like I covered everything I set out to. While there are undoubtedly some rough edges, given how the slow progress of early August pushed me almost right up to the deadline, there are no major gaps.

From Here On Out:

Two important things remain. The big one is setting up a fully working test with one server, one ruleset, and one AI client. I will do this early tomorrow and document the entire procedure. While I'm waiting for feedback, I'll spend the remaining time improving in-code documentation.

The big trip to British Columbia starts Monday. I'll still be in communication throughout, unsecured wireless networks permitting. :)

This Week:

I wrote the Single Player wiki page early this week, and expanded on it several times since. There is a flowchart showing the conceptual steps to starting a single player game in a wizard context, and an accompanying Python script which actually interfaces with the libtpclient-py backend. There are also sample XML and control script files for tpserver-cpp, the Risk ruleset (as if it were a separately installed module), and the two GSoC AI clients (daneel-ai and GenCon).

I finally managed to get an initial single player wizard screen to pop up from the connection window, after nearly a week of struggling with wxPython and XRC. I added a wxWizard base class generator to generate.py and so far it has worked.

I have mixed feelings about this week's progress. I did improve the SinglePlayer module in libtpclient-py significantly, and I know that starting games works quite well from the text-mode Python script from the wiki page. However, my goal of completing the major functionality of the wizard was far from achieved. The technical challenges of coding the GUI portion were greater than I had anticipated, mainly due to a lack of experience with wxPython and XRC.

Next Week:

Now that I have a functional wizard to work with, there are still three major pieces left to accomplish. The first is to get wxWizardPage subclasses working with XRC, which I still haven't figured out how to do. The second is to actually code the libtpclient-py interface and sequencing for the pages, which is not terribly complex but still requires a significant amount of work. The third is figuring out how to dynamically insert fields for parameters into the server and ruleset option pages, which should be similar to the Order stuff already in tpclient-pywx.

Since this will be the last week of GSoC, I also need to make sure this will actually work, and prepare a demonstration using one of the GSoC AI clients and the Risk ruleset. So far I've had success using the backend directly and manually configuring tpclient-pywx, so I am hopeful to get this going with relatively few hiccups once the wizard is complete.

This Week:

Two of three major components of single-player mode have been tackled as planned this week.

The first was specifying the XML and control script formats each server, ruleset module, and AI client should use. I will document it in detail on the wiki soon, but for now, take a look at the most current mock-up I've been using for testing and demonstration.

The second was developing the SinglePlayer module of libtpclient-py (in the singleplayer branch). This builds server, ruleset, and AI client information lists from the aforementioned XML files, presents some useful higher-level functions (more to come, as I develop the GUI part), and starts and stops the external programs using the control scripts with some intelligence.

I learned something new this week. While my C++ coding style lends itself well to making nice atomic commits with few (if any) bugs, evidently my Python coding style lends itself to being sloppy and scatterbrained. Since Python is basically pseudocode with indentation, I seem to eschew the methodical approach I take to more strongly structured languages and go nuts adding, moving, renaming, and removing code until eventually it coalesces into something reasonable. Revision control really shows this: for some fun examples, like when I pushed a commit containing value = value = ..., see previous deltas on SinglePlayer.py.

Overall, I'd say I was productive enough this week. Getting a good idea of what else remains to be done was arguably the most useful aspect.

Next Week:

I hope to make next week the big one for single-player functionality. The final major component, viz. the GUI wizard in tpclient-pywx, should be more or less complete by this time next week. Before I start, however, I also need to document the XML and control script formats, and see about having them installed with various server/ruleset/AI components. There are also various other loose ends to wrap up, and I'll take advantage of any extra time I have to work on those.

In the end, I hope for all of the major portions of my GSoC proposal to be completed next week, so that I can spend the final week cleaning up, documenting, and testing.

This Week:

I completed the libtpproto-py administration components. This turned out to be less ambitious than I anticipated, involving mainly creating an admin connection object, the various command frame objects, and a log message frame object. Everything seems to work so far.

I feel I could have accomplished more this week, but at least I accomplished what I planned. Jumping into a different language and a new set of repositories was bound to be a second slow start in the middle of GSoC for me, but I think I've built up enough momentum now to get the rest of it done in time.

Next Week:

By early next week I hope to have solid plans for two major pieces of the project: a system whereby clients can detect installed servers, rulesets, and AI clients, and an automated administration client for single-player games. I've emailed the developer list with my thoughts on single-player mode implementation and hope to get a broad spectrum of feedback.

Unless the responses effect a paradigm shift on my current plans, I'll try to code the automated administration client (probably in libtpclient-py) next week. This might involve additional work on libtpproto-py as well.

This Week:

I spent some time attempting to fit a couple other students' midterm reports to the layout I designed. I never intended to reuse it, so it consists of a bunch of manually placed text boxes and images. Along with OpenOffice Draw apparently being the black sheep of the family in terms of bugginess, my spirit is beaten, and I give up. I'm going to try to redo the reports in a less masochistic way.

On the bright side, there is now a config branch of libtpproto-py. I have begun adding administration frame functionality to it locally, but I haven't made much progress yet.

I didn't accomplish as much as I'd wanted to this week, with a number of other commitments interfering with my time. Next week, I hope to get back to coding so I can wrap the second part of my project up in this last month of GSoC.

Next Week:

I hope to complete the libtpproto-py administration extension by the end of next week. It seems ambitious, but I need to get back on track. I'm hoping that my experience implementing it in libtpproto-cpp, along with my more recent experience with Python development, will make this go smoothly.

This Week:

I added some small but important bits of functionality to tpadmin-cpp. Notably, libtpproto-cpp now handles log message frames properly, and tpadmin-cpp detects server-end disconnection and cleans up the command list accordingly.

The rest of the week was spent adding comments to the code wherever they seemed particularly important, and working on the midterm report.

Next Week:

It seems I'll be adapting the other students' midterm reports to the Thousand Parsec theme I designed for mine. Unfortunately, it's all manually laid out, so I set myself up for a relatively large amount of work here.

On the coding front, the most logical place to start with the second half of my project -- namely, adding the single-player wizard to tpclient-pywx -- is to duplicate the work I did on libtpproto-cpp in libtpproto-py, adding the administration protocol functionality. I'll see about getting a branch set up for that.

This Week:

First, with llnz's help, I fixed the connection issue in tpadmin-cpp, which had to do with the way libtprl was being used in the EventLoop context.

A ServerCommand class was added to tpadmin-cpp to handle the client end of commands within libtprl. It fills parameters from the command line string, then builds and sends command frames to the server (which also required two additions to the command functionality in libtpproto-cpp).

Once all the major functionality was completed, several bugs were fixed, and some small changes were made to improve the usability and appearance of tpadmin-cpp (such as the debug command which toggles debug messages).

This was a reasonably productive week. Although much time was spent fixing bugs, none proved particularly stubborn. The important outcome is that the administration protocol and basic client are essentially ready for release, though as mentioned in a previous post, there are potentially still some important features to be added.

Next Week:

I intend to complete testing on tpadmin-cpp with the modified tpserver-cpp, to ensure that everything works smoothly before it's merged. At the same time, I'll be poking around for other potential features (if you'd like to see something in particular, let me know).

I'll also start gearing up for the second half of GSoC, where I'll be working on the single-player mode for tpserver-pywx. Aside from the automated server configuration, this involves finding and starting AI clients suitable for the ruleset in use. I'll need to cooperate with the AI client developers to determine how best to integrate them with single-player mode in a common way.

This Week:

Early in the week, I added an AdminLayer interface to libtpproto-cpp, and a series of other commits completed the functionality over a two-day period. Notably, I created a CommandDescCache for command descriptions. More recently, I added an AdminStatusListener class, so that clients can act when the AdminLayer status changes.

The connect and login functionality from AdminLayer was implemented in tpadmin-cpp shortly after AdminLayer was created, and I later made it more robust. I also added a logger and event loop to the client, the latter of which required some design changes in the client to be used properly. I also added a ClientASL class, to implement the AdminStatusListener, which will be used, among other things, to initially populate the command list on login.

My progress this week was above average in the first couple of days, but slowed to a crawl for most of the week due to a problem with tpadmin-cpp not completing the connection with the server. This means that all did not go well, so my optional goal from last week of starting the command list population was largely unattained. I have as yet been unable to debug the connection issue, but hopefully with Lee's help I will be able to move on very soon.

Next Week:

The first thing to be done is to debug the connection issue in tpadmin-cpp.

Once that is out of the way, I can finish the command list population, which will require much work on tpadmin-cpp and probably some work on libtpproto-cpp. Assuming there are no complications I haven't foreseen, I should be able to get tpadmin-cpp sending commands by the end of next week, completing all major functionality of the remote administration component in the server, protocol library, and client in time for the midterm evaluation.

This Week:

Early in the week I finished adding the various administration frames to libtpproto-cpp in the new config branch. This provides the basic frame packing and unpacking functionality. I have deferred implementation of the CommandUpdate frame since I'm not entirely sure it's necessary.

Next, I started the tpadmin-cpp utility. The basic console functionality is there, but currently it doesn't connect to the server. When I got to this point, I realized that clients using libtpproto-cpp would connect through a high-level interface in that library called GameLayer, rather than implementing their own code for this based on lower-level stuff. So, tpadmin-cpp is now waiting for a similar interface tailored to admin clients.

Overall, I am satisfied with this week's progress. Although I missed a tentative milestone to have tpadmin-cpp connecting to the server (today), I more than made up for it with laying the foundations for other functionality that will put me well ahead by this time next week. My most important accomplishment this week has been mentally tying the ends together; I'm now fully convinced that I can complete the first half of this project on time, because I now know fairly precisely what needs to be done for every remaining piece.

Next Week:

I will revisit libtpproto-cpp and add an AdminLayer interface. This will take care of the connection, authentication, and communications, similar to GameLayer. Pending further investigation into how the existing GameLayer works, I think this should also take care of the command list.

Once the AdminLayer is complete, I will make tpadmin-cpp use it to connect to and authenticate with the server. If all goes well, I should still have time left in the week to add the necessary functionality to get commands from the AdminLayer list into the console list (which is already partially implemented).

This Week:

Unfortunately, my internet connectivity was extremely limited while I was away this week for a conference in Boston, so I wasn't able to accomplish much actual coding work (in fact, I managed to total two commits all week).

However, I did get a chance to review the libtprl and console code reasonably thoroughly, and the currently available libtpproto-cpp briefly. My familiarity should give me something of a head start in implementing the client, and indeed, it looks as if it should be relatively straightforward.

Additionally, I spent some time reading up on UNIX sockets. I've used them (in a sort of quick-and-dirty way) before, and having refreshed my memory I can say that this, too, looks quite doable. I'll need to double check but I think socket-based IPC is quite standard and portable.

Next Week:

Back home and armed with knowledge, I plan to hit the ground running and make some major pushes in the upcoming week.

The first order of business is to branch libtpproto-cpp in order to add the client side of the administration protocol extension, to be used by the C++ CLI administration client.

If I can fully complete that next week, I'll be on track to have a fully working client ready for the midterm evaluation date. However, I hope to wrap that up early and move on to starting the client itself before the end of the week.

This Week:

There is now a fully functional CommandManager in tpserver-cpp. It implements a basic command set similar to what was once in the console, and allows modular addition of new commands (from rulesets or plugins, for example). It also implements the command description portions of the protocol extension, in a fashion similar to order descriptions in TP04. Together, the CommandManager and Command classes already implement just about everything necessary for commands on the server side.

My plans to continue expanding the Python mini-client are on hold, since Lee reports that libtpproto-cpp is nearly ready and I should start working on a branch to add admin extensions soon. Most likely, I will relegate this work to when I branch libtpproto-py similarly for use in tpclient-pywx's single-player mode.

In the meantime, tpserver-cpp now also runs as a daemon (quite properly, I think) by default. The interactive console has been removed accordingly. I ran with it and wrote a Gentoo init.d script, which is able to start and stop the server daemon as user "tpserver-cpp" nicely. On a related note, while I was editing my local tpserver-cpp ebuild (which builds from my working copy of the config branch), I modified it to import games.eclass and install things to the proper games directories.

I'm satisfied with the pace of my progress. Based on my original milestone goals, I'm about 2 weeks ahead of schedule, although it's a little lopsided since I don't have an actual client yet. If I can hammer out the client reasonably quickly, I should be more than on track to finish up the server stuff by the midterm evaluation.

Next Week:

The plan now is to start developing a C++ command-line client for normal administration, to replace the console (but with a few new commands and remote access). This will be based on the console and libtprl code for the actual interactive shell, and libtpproto-cpp for communication and the protocol. I'll spend some time working on the former until libtpproto-cpp is ready.

Another thing I may look into next week is adding a UNIX IPC socket for administration connections, which would be better than TCP for local administration. This is a fairly important goal since a large proportion of cases will benefit from it, but it isn't absolutely necessary for the time being. When I get to this will depend on how the client development goes.

I have a conference to attend in Boston next week, from Tuesday to Friday. Hopefully the hotel provides wireless access so I can work remotely...

This Week:

The administration protocol extension is now specified in the XML format using the protocol DTD. It uses some of the existing basic frames and most of the new frames are closely related to the Order family from the main protocol. This may not be the "final" specification, but at this point I think the only likely changes are additions.

Logging to administration clients is now fully working in tpserver-cpp. To resolve my previous conundrum, I ended up passing a reference to the AdminConnection object to AdminLogger via a setConnection function, similar to the relationship between PlayerConnection and PlayerAgent. Logging now uses an asynchronous message type similar to AsyncTimeRemaining.

Awaiting updates to libtpproto-cpp before starting the C++ CLI administration client, I've been evolving a little test client module based on libtpproto-py in order to send and receive administration frames and make sure everything is in order on the server side. So far, I've succesfully used it to test, as previously mentioned, everything in the connection up to "logged in" status, and more recently, remote logging.

There is now basic functionality for processing all the administration frame types after logging in on the server side, although at present none of it actually does anything other than some sanity checking.

All told, I'd consider this first official week a fairly productive one, considering I was completely offline for four days of it. Since I started with this project I've had endless distractions from the various other items on my plate; happily, I've still managed to keep pace with my milestone goals. I'm looking forward to putting in a lot more solid time now that most of that is behind me.

Next Week:

The main goal for next week is to develop something analogous to OrderManager for commands, although it probably doesn't need to be so complex. This object will centrally store the command set and descriptions, and provide functions for replying to request frames. At present, I'm thinking the same object will also be used to process incoming command frames, check validity, execute the commands, and form the command result frames.

Along with this, I'll keep expanding on my test client module to prod server-side functionality as it develops, and eventually some of it may end up in the tpclient-pywx single-player wizard and other Python-based stuff.

This Week:

The new additions to tpserver-cpp now compile, and have been pushed to the config branch of the repository. The server now accepts TCP connections for administration, properly starting and stopping the sockets, and performs version checking and authentication. Relevant configuration parameters have been added to the sample configuration file.

The administration protocol extension frames have been specified, and they are ready to document formally.

Next Week:

The administration protocol extension will be formally specified in the XML format.

In order to proceed further, a basic client capable of sending and receiving frames will be required. Lee is currently working on libtpproto-cpp, but I will familiarize myself with it for now and start coding the client when it is ready. If there are further delays I plan to start looking into implementing the administration extension in libtpproto-py and/or libtpproto2-py as well.

This Week:

I created AdminTcpSocket, AdminConnection, and AdminTcpConnection objects, based on their Player (game protocol) counterparts. The command functionality will live in AdminConnection.

I have discussed the administration protocol and its implementation in tpserver-cpp with Lee and on the mailing list, and now have a workable plan. The protocol will be based on the game protocol, using a process similar to order descriptions and orders to exchange information and commands. There will also be asynchronous frames for log messaging and possibly command set updates. The main CLI administration client will be separable from the server for building and/or installation.

I set up a wiki page about remote administration. It currently includes the overall plan and milestones, some initial details about the administration protocol, and documentation on the command set from the console.

Next Week:

I plan to finalize the administration protocol specification next week, documenting it in the protocol XML format.

I also plan to work on integrating the administration protocol in the Frame object of tpserver-cpp so that the server compiles and listens for admin connections with the new objects. When this first objective is reached, I will push the changes to the config branch.

This Week:

I have a branch "config" of the tpserver-cpp Git repository set up for my modifications.

My plans for tpserver-cpp can be summarized as follows:

1. Strip the internal console out, remove libtprl dependency.


2. Daemonize the process (with a switch to disable for debugging).


3. Implement objects for sockets and the protocol.


4. Hook the protocol with the actual commands.

I had a few discussions with llnz about parts 1 and 3, and I have a pretty good idea what needs to be done. Part 2 is fairly straightforward and I have a few references to make sure it gets done right. For part 4, I've documented the current commands and precisely what they do, so this should not be difficult once the protocol itself is in place.

Next Week:

I plan to spend the bulk of next week getting familiar with the TP game protocol and starting to design the administration protocol similarly.

Also, I plan to move my tpserver-cpp documentation onto the Thousand Parsec Wiki and flesh it out more. This will be a good place to see the details of my planned changes to tpserver-cpp, and I will keep it up to date as the actual coding progresses.