I’ve pushed out version 0.0.3 of Wintermute recently. It’s still some toy at the moment but it has a packaged configuration system as well as a libuv-backed event loop and support for ZeroMQ as a quasi-message broker’s coming. What’s missing now is the daemon needed to kick off core plugins like the external relay to outer networks, more tests to cover feature scopes and another roundabout to see how JNI support would work. Before this even hits a 0.1.0 release, I’d want to see this ported to at least Android 5 so that I can start hacking on Android projects whilst messing with Wintermute. This is a lot of random jazz without context so I’ll cover that below.
Configuration, Event Loops, Oh My!
In a previous post, I’ve mentioned how I used libuv to build a
tool, similar to the one in Node so that Wintermute could chain events and
actions together in a relatively transparent fashion. This is vital for handling
socket connections and implementing an asynchronous callback system in C++. or
Wintermute’s also making use of a relatively flexible configuration system that follows the syntax of JSON but with a few enhancements. Nothing crazy, but it does make way for other things like changing ports or sockets to be listened on and allowing user-provided options for a long of the immutable data.
Dropbox currently uses C++ to handle the core of their product1 and me being ever so interested in C++ figured that keeping Wintermute’s internals in C++ was a good choice in terms of speed and targeting strengths of particular platforms2. In order to get better support for the Android platform leveraging JNI and working in favor of the virtual machine made the most sense. I’m still running through the documentation under Android about it but it looks a bit hairy, as with all of the tools out here. The goal of this is to have Wintermute’s configuration and RPC support all in one package. Having that be part of the core Wintermute package gives me a bit of control of what parts of Wintermute that I know I can use and maybe if ever off grid with a bit of space can use the phone as a stand-alone instance. Who knows 3?
Testing’s important if you care about keeping track of progress and preventing
old issues from coming back up. This is something I didn’t tie into Wintermute
when I started it out back in 2012. I did manual tests that require debugging
statements, constant rebuilds and manual driving of code. Bad way to go about
things. I’ve added quite a few unit tests for Wintermute to cover how each
class should operate but I’m debating adding more feature-level tests using
something like cppspec4. On that note,
CxxTest is bulky and adds
another development build time dependency for Wintermute, hence my want to move
all of the testing to use greatest. Research, research.
Testing’s good, y’all; it keeps them thinking caps of yours sharp.
Realistically, this is my laptop, a Nexus 5 and a Raspberry Pi B+. ↩
I do, this is a goal since a lot of commute is underground nowadays. ↩
That project hasn’t been updated in quite some time, so I’d walk ↩