gruelbox/orko

Script: event.ticker() deceptively named

AwooOOoo opened this issue · 1 comments

AwooOOoo commented

Describe the bug
I would expect a ticker to be periodic (and ideally something I can set the frequency of). The event.ticker() is triggered on a trade and so the events are as sporadic as when the trades come in. It would be better named as event.trade() as it is currently implemented, then you can turn this into a ticker yourself.

To Reproduce
Steps to reproduce the behavior:

  1. Create a script that prints a price (i.e. use the example script that shows the price of an asset: https://github.com/gruelbox/orko/wiki/Scripting
  2. Watch the Market History section of the Market Window and compare it to when server notifications appear
  3. Notice they always trigger at the same time and sporadically

Expected behavior
Either:

  1. An evenly distributed ticker (i.e. once per second or configurable)
    or
  2. A more correct name for the event

Desktop (please complete the following information):

  • OS: Ubuntu 20.04
  • Browser: Chrome
  • Version Version 84.0.4147.125 (Official Build) (64-bit)
badgerwithagun commented

This terminology is inherited from XChange where a ticker "ticks" when either (a) there is a material change in the price data of an asset - if you're using the streaming API - or (b) every few seconds (if you're polling). The former is obviously preferable if you can get it, so your option (2) seems preferable.

XChange also has a "trade" event that specifically fires when there is a trade, containing details of the trade. This isn't currently exposed in the script API because I've never got around to it (PRs welcome!).

They don't quite fire at the same time. In fact, Binance only sends a ticker at most once a second I believe, whereas trades are sent immediately. Also, a trade might not change the ticker data if the exchange doesn't provide aggregate data such as daily volume and you have two trades successively at the same price and direction without chewing a level of the order book.

I'm open to the idea of an alternative name if we can find one that works, but it will be confusing to developers to have one set of terminology in the script API and one internally.