You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the design of utxorpc is such that you have to create multiple watchers for different actions
The problem with the current design is that it makes it hard to know if you've received all the data up to a specific block. For example, imagine you have two watchers A and B:
A receives event for block 30
B received event for block 40
You can't know if this means there are no events for A at block 31, or if it's just because you haven't received the result yet. Even worse, you don't even know if the event for B is the only event for block 40 (there maybe more you just haven't seen yet)
There are two main ways to solve this problem I think:
Instead of watching, poll with a max slot. Since you're providing a max slot for the request, you know there is no data up to that slot once you get the return (downside: polling frequently is less efficient than watching)
Return objects that indicate a lack of any events (ex: at block 41, there are no events for B)
Note that in either case, this has a non-trivial increase in the number of requests made. In Ethereum land, they try to solve this by allowing you to combine multiple watchers as a single request (see eth_subscribe and eth_newFilter), but these are non-trivial to implement and require server-side state (which maybe goes against the design of utxorpc if the goal is to be stateless)
The text was updated successfully, but these errors were encountered:
Right now, the design of utxorpc is such that you have to create multiple watchers for different actions
The problem with the current design is that it makes it hard to know if you've received all the data up to a specific block. For example, imagine you have two watchers A and B:
You can't know if this means there are no events for A at block
31
, or if it's just because you haven't received the result yet. Even worse, you don't even know if the event forB
is the only event for block 40 (there maybe more you just haven't seen yet)There are two main ways to solve this problem I think:
at block 41, there are no events for B
)Note that in either case, this has a non-trivial increase in the number of requests made. In Ethereum land, they try to solve this by allowing you to combine multiple watchers as a single request (see
eth_subscribe
andeth_newFilter
), but these are non-trivial to implement and require server-side state (which maybe goes against the design of utxorpc if the goal is to be stateless)The text was updated successfully, but these errors were encountered: