Kindly do not modify the relay.py, it will break your flow in the future as it is a core component.
That is why there is client.py in which you write the code. All vendor_library comm is placed here.
When BrokerWS, ArcticDB etc gets integrated, relay logic is only going to increase in complexity.
in future, it may be made into a service once stable, and some UI shortcuts for it. I know right now you need 1 terminal to keep it running. But it is good as you can see some debug messages instead of running it in the background.
Are these the list of commands or queries we get from WsRtd plugin?
bfall (BackFill)
bffull (BackFill)
bfauto (BackFill)
addsym (AB/user requesting new symbol)
remsym (AB/User request to delete symbol)
bfsym (Backfill)
Is there any other communications our dll plugin can do? I know you are working on a full scale system but just wanted to see if this in pipeline or would be a bad idea to add new some more additional commands which can be used for other purposes.
@nsm51 It is great to see that we have got customised plugin from you. It is very great initiative. I am also a non programmer trying to understand AFL and getting realtime data from the broker. I was forcebly opened my IB account for the sake of data but now i think i can integrate from my broker. Can you please share me the dll please.
There are many fields, and AB itself supports Bracket orders for example. so it should be wholesome and I don't have old code like data plugin to test.
In client-app you don't need to maintain so much state like you have to in TI, only the recent bar is enough in one dataframe.
In the client-app order_class_wrapper i am writing, there are 4 DFs.
Anyway, code is submitted to AB for review/approval.
So you mean you have to maintain an array of orders?
Btw, an order can be filled or not, or even partially filled. Can this be accounted for? Or AB presumes if it sends an order it will be filled? Is there an async mecanism to update the order's state?