Google Protocol Buffers...
Glenn H Tarbox, PhD
I've done quite a bit of reading and checking on this since yesterday
and my conclusion is we should embrace Google Protocol Buffers (PB),
perhaps in general, but certainly for the time being with the OpenTick
and IB integration efforts.
There are 3 types of interactions with the server.
1. Conventional RPC with request/response. Essentially, the call
returns "immediately" from the server's perspective. The client
can block or implement asynchronous callbacks.
2. RPC with finite response - when the server itself needs to wait
for data from the IB application (because it needs to call IB
over the wan) the RPC return should be an id to be used to
associate callback based responses with the request. The client
will need to implement an API to be called back with the data.
Sometimes its a single callback, other times its more involved
(e.g. search responses, portfolio updates etc)
3. RPC with infinite response - infinite might be a bit larger than
I mean, but here I'm talking about things like market data where
we're registering a general callback for the data we're
"subscribing" to.
IB seems more straightforward so we'll start there. For the most part,
I think we can just map our api to IB's java api for EWrapper and
EClientSocket. Support objects like Contract, ContractLeg etc. can
likely be modeled using data structures. Convenience methods we provide
for specific languages to help construct these objects is a separate
issue.
The OpenTick architecture is a bit more complicated in that we have a
lot of options and cython. The good news is that the api is less
complicated than IB's because we're just grabbing market data, not
executing trades or getting related information.
With OpenTick, nothing has changed... yet. We should wrap the API and
get the data into cython / python. However, with OpenTick, performance
is critical (particularly if we ever start doing things with Xasax). At
that stage, we might want to extend the lower layers to provide a PB
transport to remote clients. This would mean pure C/C++ from the source
to the final consumer. For now, this isn't critical, but if we start
really suckin' from the pipe, it could make a huge difference.
We should give one look-see at the Java api for OpenTick although I
doubt it makes sense given C++ and cython... but we should look to make
sure.
-glenn
--
Glenn H. Tarbox, PhD || 206-494-0819 || gl...@tarbox.org
"Don't worry about people stealing your ideas. If your ideas are any
good you'll have to ram them down peoples throats" -- Howard Aiken