Question: about the future

[7jrxt42BxFZo4iAnN4CX]

How do you do? I would like to ask if there are plans to implement the request. And how long would that take?

I just started studying rust and I don't know if I can help yet. But I'm interested in the idea of having rust API instead of Java.

[wvietor]

Hello! Right now I'm working on cleaning up the codebase with some better error handling. Thereafter, I'll work to implement the missing functionality. A lot of the requests are already implemented though — market data, placing orders, historical data, etc.

[7jrxt42BxFZo4iAnN4CX]

I get it. The list for implementation just looked and could not find some functions in eclient. But I didn't look good, because there's a lot I don't understand yet. (e.g. macros). Just finished the official book and started studying tokio. I watched a lot of crates and it looked like an official... And many others are no longer maintained and look strange. I wonder why nobody's here.

[wvietor]

Yeah, I am missing some client functionality. And yes, the existing rust crates aren’t great. A lot of them don’t really take advantage of rust’s type system and just port some of the bloated IBKR classes to rust. My goal with this crate was to try to encode as many of the API requirements into the types themselves — eg. IBKR doesn’t have “TRADES” historical bars for forex, so you’ll get a compiler error if you try to do this.

After I finish the new error handling, I have to write some wrapper functions to finish handling some existing requests, but I will work on adding the other client methods. The only functionality I wasn’t planning to implement was the “combo legs,” bond-related requests, and the fundamental/news requests.

Also, I have written a fair bit of documentation. You can access it by running “cargo doc” from the crate directory. It outputs a bunch of html in the target/doc directory, which you can look at from the browser just like any ordinary crate docs. This should make it easier to understand the functions without having to read all the source code. I think there’s some info about the docs in the rust book too if you have more questions.

[7jrxt42BxFZo4iAnN4CX]

Types. That sounds interesting. But will it be possible to make these guarantees when subscribing to a scanner, for example? All possible options could be obtained by calling reqScannerParameters() in XML format. (If nothing has changed, I haven’t looked at the IB API for a long time.) It will probably be difficult (or long).

When I saw a file named “Functions to implement.csv”, I thought that you wouldn’t want to implement all the functionality. I just need combo legs and news too. For example.

Now I’m writing a training project in Rust, and then I’ll probably try to dive into your code to understand how difficult and time-consuming it will be to implement what is needed. Perhaps error handling will already be ready by then.

[7jrxt42BxFZo4iAnN4CX]

@wvietor I'm back. To begin with, I'll try to implement the scanner. And test this functionality in the tests/test_scanner. Should we track the API limits? E.g maximum of 10 scanner subscription requests at a time and maximum 50 requests per second.

[wvietor]

Hey! I think tracking the limits is a good idea. Saw your commit -- will merge it shortly.

[7jrxt42BxFZo4iAnN4CX]

@wvietor ok. Let's create pull request for Limits a little later. Now busy is over the XML transformation into types / functions.