A while back I made a start on building the client using WPF, the Windows Presentation Foundation. It only made sense to give it a shot since the whole MUD is based on C# and .NET.
That effort stalled due to a roadblock or two, probably because I didn’t know about routed events and partly because I didn’t understand RegEx very well. I have a better handle on regular expressions thanks to spending some time with the Django web framework.
In the process of trying to rework the C++/wxWidgets-based client to support the new tiled map graphics I’ve experienced a lot of pain. The kind of pain that can only be explained by the fact that a string is not a first-class object in C++ and that text parsing can get to be unbearable when you have a complex stream over TCP.
That has prompted me to take a look at the WPF version of the client again. Rather than being based on some ugly recursive character-by-character text processing code, it’s based primarily on regular expressions — one to parse out the ANSI codes, and one to process the XML tags for the various client data (life meter, map info, room description, etc.). The first one was done when I left off, but the second piece hadn’t been started yet. Well, it’s in place now and I can continue building the rest of the newer client.
Getting the WPF version up to and past the usability of the wxWidgets version will probably be faster than untangling the text parsing in the spaghetti code.
The .Net regex are really powerful, but if your parsing structured data like formatting tokens, or especially XML a lexer/parser will give better (performance) results. If you are controlling both ends, you know the source will be “good”.
True. In this case performance isn’t much of a concern because we’re dealing with a data stream that averages out to less than 9600 baud for the life of a session (though it will burst much higher in spam battles). The convenience and power combination of regex is ideal for this app.