Another motivated week. This week was rebuilding some simple stuff for subscribing to market data. This is ironic as it it almost exactly two years ago that I (and some others) converted our trading floor to multicast. It is nice to see others finally discovering the benefits of multicast market data delivery, even if they forget that it is not a new thing for everyone. Anyway, this subscriber, like most tibco hacks, turned into 'Yet Another Wrapper for the TIB API'. This time with C++ and the stl. If they only would provide a nicer API to start with ...
The TIB API is a legacy beast, a C API that does the job, but without beauty (the formclass code makes most shudder at first look). Back in the days when most software had one thread it was really quite good. It provides an event-idiom interface to market data, file descriptors, signals, and timers. Think of a wrapper for select with a nice heap of timers and some signal traps and callbacks for market data thrown in. After the first few simple applications a programmer generally develops some wrapper that is more to their coding style. I suspect this is approximately wrapper number nine for me.
Others may want to point out RV. Yes it is a much nicer API, and for simple messaging the RV transport is very nice (especially distributed queues). But on a 100Mb network at market open with thousands of updates blurting across the wires, CI still beats RV. Function wins over Form.
After the discovery that jonathan had signed up, I spent a little time looking over Arusha. I perceive their goals as being quite firmly rooted in Academic installations. Most corporate entities will work hard towards making their infrastructure homogenous in order to ease maintainance. The Arusha project talks about infrastructures of dozens of systems. My last trading floor (built in 1998) is currently serving between 800 and 900 desktop machines with one point of influence for packaging, and one point of influence for account and system management. I had the huge advantage of being required to support only one hardware manufacturer (but all of that manufacturers architectures and both the shipping major OS versions). To handle multiple unrelated architectures and OSes is a very tough thing and, outside large Universities, of limited appeal. Look at the fun Chris Coleman is having with openpackages and consider that this project is just to try and unify applications for BSD ...