Older blog entries for jonathon (starting at number 1)

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 ...

27 Aug 2000 (updated 6 Apr 2003 at 12:58 UTC) »

I spent the afternoon with two things (neither open source): perl glue for SSL, and BeOS. Hacking SSL was partly business. Then, for fun, it was time to play with BeOS.

The perl glue for SSL is not secure sockets layer, but Reuters Source Sink Layer. A few years ago I wrote a Tibco feed-handler for my employer to slurp data from the Osaka Stock Exchange. The OSE used Reuters as part of their implementation of price data delivery to members. Reuter (via Fujistsu) sold them SSL. Over a pint we and a friend considered writing perl glue for the SSL, so this afternoon I threw C and perl into the mix. I will do some tidying later, but the feel of this module is to implement the glue in the perl/c api and implement the object feel in perl. (A couple of years ago myself and the same friend implemented an object oriented Tibco ciServer api for perl. We implemented as much of the OO as possible in the glue. I think that was a mistake - we should have implemented the glue as an 'API' perl package, then implemented the OO concepts above it in perl.). This afternoon the glue substrate was formed and I filled in a couple of the functions. Reuters contributions via perl to follow...

BeOS. BeOS is cool. Between linux, w98, w2k and BeOS, the only OS that can really handle real-time ieee1394 video is BeOS. Besides, it is a lovely creature to write code for (aside from the clunky free IDE). Highly recommended and besides, it could do with some filling out with applications.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!