Exposition-- all yarns need one

In the wake of the recent turmoil in the financial markets, I found myself with, shall we say, extra time on my hands. So after several reflective walks with a cigar, tending to all the pressing items in the garden, and new job hunting (not to mention a healthy dose of time-wasting on the internet), I decided to look for a project that would keep me occupied in my off-hours and afford me an opportunity to learn some new, marketable skills. This is when I considered taking a look at 29West’s low latency messaging products.

Several jobs ago, I worked with Matt Meinel, 29West’s global director of business development, at an investment bank both here in the UK and in Chicago. Some time after we parted ways, Matt contacted me to introduce me to 29West’s technology. Now, I’ve done a lot of middleware and messaging in my career and have even lead the creation of a commercial market data distribution product, so I had grown somewhat fatigued with the messaging space. But I found the ideas embodied by the 29West technology so intriguing that it rekindled my interest in messaging. And when I considered the arms race that was and still is raging around latency amongst the participants in electronic trading, I figured that gaining some experience with 29West would be a good way to broaden my experience in a marketable way. So I gave Matt a call and got access to the product suite.

After spending some time with the documentation and examples, I felt I wanted to start tinkering with the technology. The question was, in what form? Coming up with a reasonable project that exposes you to many aspects of a product is always a dicey affair. Often you do something that is reasonable in scope but winds up not touching a lot of the product’s API (and 29West’s product has a big API), or you contrive something that takes a lot of the product’s capabilities into account, but your project becomes so enormous that it takes on a life of its own, almost like you’re building a new product rather than trying to get experience with an existing one. I needed a project that would avoid these pitfalls but still give me broad exposure to the 29West API.

That’s when it occurred to me to develop a Python extension for the 29West technology. As a project, it had a lot of the features I was looking for:

• Wrapping the API would entail touching all of its parts.
• No higher level application need be created (except for examples); exposing the semantics of the API would be the end in itself.
• I would be encouraged to think critically about the API in order to put a more “pythonic” face on how the API was exposed.
• Having a Python extension for 29West would provide me a more productive springboard for some of the other projects I had considered.

But Python? It’s not the first language choice that springs to mind when you’re considering the low-latency messaging space. But the goal wasn’t white-hot performance; for that, nothing but the C API would suffice. Besides, this was to be an exercise of exploration and understanding, not necessarily for creating a product. And I knew from my experience with Python that while I probably wasn’t going to get it to drive trading on electronic exchanges, it would perform well enough for a large number of applications that someone would consider to use 29West for. Given all of the above, a Python extension to 29West seemed a fine project.

Which brings us to this blog, a development diary of sorts. It has occurred to me that someone might actually find hearing about this exercise useful, and so I’ve decided to make the project’s progress public, even if I occasionally wind up with a bit of egg on my face. What I intend to do is discuss goals, designs, tools, and implementations of the code I create to wrap the 29West libraries and make them available via Python. Such an exercise can’t avoid entailing a bit of a critique of the underlying product, and so I want to recognize 29West for voicing no objections regarding this endeavor.

I hope you find something valuable in the posts to come.