Design choices

Design choices

Nobody asked me any questions yet, so instead of a FAQ page here are some things I asked myself. I don't claim to have the best answer in each case, but hopefully the end result is good enough for its intended purpose. Like most of the people likely to look at this page I'm fairly new to this type of programming, and we're all learning by trial and error.

Why the client-server design?

The original, not-so-good answer is that I failed to find a simple, lightweight way to put a command shell inside a graphics window, to handle GetLine(), cout, etc.

Once I got deep into writing gserv (my first GUI program for Linux), a better reason became clear. GUI programs are inherently more complicated than console programs, and their event-driven model requires giving up a lot of control over the top-level structure of the program. It's not especially hard to learn, but would be a distraction from the goals of CS106B. The client-server way, all that complexity is hidden within gserv, and the student code only needs to handle stdin and stdout within a scrolling terminal (e.g. a bash shell). That's handy - I'm a student too, and I'm still working through the programming assignments.

Note that using multiple programs, independent except for some message-passing, is a venerable UNIX tradition. A process like gserv isn't exactly groundbreaking.

Why use Qt?

Addressing X11 directly looked too difficult, at my current level of knowledge. It's also not very portable (e.g. to Windows).

Qt, GTK+ and wxWidgets were all viable cross-platform options. I ended up using Qt because it's native C++ code, and I'd had a small amount of practice with PyQt previously. No regrets - I became very impressed with Qt's design, implementation and excellent documentation.

Why connect via TCP sockets?

After a bit of reading around, these seemed to be one of the more robust ways to do bidirectional communication, easier and more portable than shared memory or RPC calls. In particular they're one of the few UNIX methods to become universal on Windows. Unfortunately, I was slow to realize that Windows implements them in a different way - so this code doesn't yet work on Windows. Life is full of ironies.

Why such simple ascii-format messages?

"Simple" is good! Binary formats are possible and maybe quicker when running, but much harder to debug. Maybe using quoted strings would have been better (for things that can include spaces, e.g. "DRAWTEXTSTRING the rest is one all parameter").

You pass all the message strings by value, not reference-to-const?

Sorry, that bit was one of the first things I wrote, when my ignorance was (even) more comprehensive. The code may change in a future release.

My Boggle screen takes a long time to draw - why?

Firstly, if you are showing the debug log you should hide it. That increase the time at least 4-fold.

Secondly, all effort so far went into getting the libraries to do the right thing, without worrying (yet) about performance. For "premature optimization is the root of all evil" and related quotes, see http://en.wikipedia.org/wiki/Program_optimization