Enhancements to streaming API

[smk762]

Extends https://github.com/KomodoPlatform/komodo-defi-framework/pull/2172

While drafting https://github.com/KomodoPlatform/komodo-docs-mdx/pull/457 I collected a few notes and nits:

• in the stream::fee_estimator::enable, the estimator_type must be Simple or Provider (title case), but the gas_api.provider parameter in MM2.json uses lowercase simple or provider. Consistency is nice, but so is forgiveness, so alternatively we could accept either without error.
• Using stream::tx_history::enable on a coin which was not activated with "tx_history": true in the activation command, no data will be forthcoming. Can we please add error feedback in this case to help guide the user to rectify their mistake? In general, any case where an error occurs leading to streaming data not being sent, console logs (or an error message being sent to the stream client) would assist with debugging.
• Most methods taking coin as input accept a string only, for a single ticker. It would be nice to be able to pass a list of tickers (and receive a list of streamer_ids in response. This applies to tx_history & balance . It could also be applied to disable to allow closing multiple stream_ids at once. Applying it to orderbook is a little more complex.
• Where a CoinNotSupported error is encountered, the response should indicate which coin types are supported.
• A new method like stream::ids::list would be great, to return a list of all active streams.
• apply a default client_id=0 in streamer disable request just like what we do in streamer enable requests.

[BigFish2086]

I'd like to work on this issue.

[BigFish2086]

Most methods taking coin as input accept a string only, for a single ticker. It would be nice to be able to pass a list of tickers (and receive a list of streamer_ids in response. This applies to tx_history & balance . It could also be applied to disable to allow closing multiple stream_ids at once. Applying it to orderbook is a little more complex.

I have some questions regarding this one:

1. I’m assuming we want to support both the current behavior (where coin is a single string) and the new one (where it can be a list of strings). For example:

{
...,
"coin": "ETH",
...,
}

and also like this:

{
...,
coin: ["ETH, "BCH"],
...,
}

Is this assumption correct?

2. Also, for the response, should we preserve this one:

{
...,
"streamer_id": "TX_HISTORY:ETH",
...,
}

i.e having streamer_id as a single string in case of the request being about only one coin or should we have it as a list in all cases

3. How should errors be handled when passing multiple coins? For instance, if some of the provided coins are balance_enabled and others aren't, should: The entire request fail with something like BalanceStreamingRequestError::EnableError, or We return streamer IDs for the valid ones and also report the errors for the invalid ones?

[mariocynicys]

hey @BigFish2086 ,

1. I’m assuming we want to support both the current behavior (where coin is a single string) and the new one (where it can be a list of strings). For example:

yup, but let's use coins in the second case where a list is passed.

2. Also, for the response, should we preserve this one:

for the single coin case, a plain id should be returned. for the list case, a list of ids should be returned (either in the same order as the coins in the request or we figure out some mapping/id to identify which response is for which coin)

3. How should errors be handled when passing multiple coins?

since the list suggestion is more for convenience, different coins wouldn't really have any corelation, so we can just return a list of responses which can be successes or errors or a mix of both. (i.e. if balance streaming fails for one coin (say eth), we should continue trying to enable balance streaming for other coins in the request (say btc & bnb), and we will return a list [error_for_eth, success_for_btc, success_for_bnb])

that's only imo. we might end up not wanting this specific technique when discussing in the PR (but that will only really affect the request/response structure/format so not much of an issue). you can leave this feat to the end though.