Alternative implementation based on official cppclient

[vspinu]

H!

I am embarrassed to acknowledge that I have just discovered your repo 😞 I have written my own version of the R IB client, and I even named it the same 😄 Had I known about your package I would most surely not had attempted mine.

I wrap the official cppclient with its obvious advantages like speed and almost out of the box 100% compatibility. The disadvantage, cannot release to CRAN and the user needs to download the official api client code.

I also go quite a bit further than by providing an interceptor style handling of messages which could be used for building complex data processing patterns and bots. The idea is to make the experience quite a bit more user-friendly by providing object constructors and data fetching functionality which would work out of the box.

Obviously, I would love to join efforts but, as you could guess, by now I am inclined to do it the cppclient-way 😄

Would love to hear your thoughts.

[lbilli]

Hi,
nice to hear about your package.

In my first attempt I also went down a similar path which involved using Rcpp to wrap the official C++ client.
However, I found out that, on top of the burden of dealing with two languages, subsequent IB updates would easily break the built and extra work was often required to keep the two in sync.

So I figured that it could be a fun project to go full R; after all the communication protocol is not that complicated.
So far it has been quite straightforward to support all the features and the maintenance needed to keep up with the official clients is minimal.

Moreover, that exercise paved the way for me to do the same in Julia and the sister project Jib.jl was born, which is the one that I actually use.

[vspinu]

Yeh. Makes sense indeed. It's a clean setup that you have brewed with those prototypes. I already see a few things I can borrow, he he 😺

I almost agree with the "protocol is not that complicated". All those version checks and conditionals are way to much work to track and duplicate. The C++ mapping has its drawbacks, it's not entirely trivial as you still need to move structures back and forth and thus need to know the fields. But at least one does not deal with the encoder and the decoder.

Regarding the breaking, it did happen once in a year so far, but maybe it's a good thing - will force me updating the repo to the new features.

[lbilli]

All those version checks and conditionals are way to much work to track and duplicate.

I agree and I have no interest in supporting decade old TWS.
For the sake of simplicity and cleanliness, I dropped all that cruft and going forward I intend to keep compatibility only with the most recent (~2 year old) versions.

[vspinu]

it did happen once in a year so far,

I just bit my tongue 😭 Since half a year they did the decimal change and changed loads of types all over the place. No way I can keep it going the way I intended. I will start pinning branches to their released versions and develop on the most recent. Will see how it goes. If it turns too be difficult I will drop it completely and rebase my abstractions on top of your package.

[lbilli]

Since half a year they did the decimal change and changed loads of types all over the place

Yeah, I didn't jump on that train (see #11) and adopted a wait-and-see approach instead.
Even if you traded all bitcoins in one go, the quantity could be still represented fully by a 64-bit float.
So I stick to 64-bit float for now.

After all, deep down the communication protocol is based on good old ASCII strings and it's not aware of which types, numeric or otherwise, you convert those strings to or from.

Of course, when you rely on the official clients, those conversions are already baked in and you have to deal with them 😏.

[vspinu]

The client supports only a handful of types In comparison to the full list of what is available. Do you have in plan to extend that?

Is it fair to say that rib implements

• Full decoder
• Full client in terms of available methods
• Partial parameterezation of the client methods because of the limited encoding capabilities of the input parameters

Or do you also cut some corners elsewhere?

[lbilli]

All types are already exposed and usable. As they are plain R lists there's no need for special constructors; a simple copy will do:

# Instantiate an ExecutionFilter with default values
e <- ExecutionFilter

# or a ComboLeg
c <- ComboLeg

The role of factory.R is mostly an educational one: it shows how to quickly write a helper function that returns any type that has been prefilled with customized values.

rib mirrors very closely the official clients in terms of methods and data layout and it can replicate any of their functionalities.
The only limitation is the inability to connect with older servers, currently meaning pre 9.81.

[joshuaulrich]

@lbilli Sorry to jump in with an off-topic comment... but I couldn't find another way to contact you. Could you send me an email maintainer("quantmod") to discuss possible collaboration?

[lbilli]

You can use the email in the DESCRIPTION.

[joshuaulrich]

Will do. It looked like that email went to /dev/null haha

[joshuaulrich]

Sent a couple days ago. Did you receive it? No rush to reply, just checking you got it.