Users of the library may want to be notified when a block or log that matches certain criteria arrives. At the moment, they have to subscribe to the firehose (that they have added filters for) and then filter off of that. It would be nice if the user could do something like:
The library would deal with dynamic dispatch for the user, giving them a simple interface for supplying filter functions and callbacks without them having to build a dispatch system themselves. This solution wouldn't couple blockstream to any particular filtering strategy which is nice because it keeps blockstream library fairly agnostic to dApp's usage of log/block data.
Another potential option would be to support one-shot filters. These would be filters that will fire a callback once the filter function passes and then un-install themselves. This would allow users to subscribe to log/block events that they believe are coming. Potentially, adding a timeout (number of blocks filter will live for) would further simplify user experience by allowing them to hookup one-shot filters for logs they think will come in eventually, without the user having to deal with eventually giving up.
Users of the library may want to be notified when a block or log that matches certain criteria arrives. At the moment, they have to subscribe to the firehose (that they have added filters for) and then filter off of that. It would be nice if the user could do something like:
The library would deal with dynamic dispatch for the user, giving them a simple interface for supplying filter functions and callbacks without them having to build a dispatch system themselves. This solution wouldn't couple blockstream to any particular filtering strategy which is nice because it keeps blockstream library fairly agnostic to dApp's usage of log/block data.
Another potential option would be to support one-shot filters. These would be filters that will fire a callback once the filter function passes and then un-install themselves. This would allow users to subscribe to log/block events that they believe are coming. Potentially, adding a timeout (number of blocks filter will live for) would further simplify user experience by allowing them to hookup one-shot filters for logs they think will come in eventually, without the user having to deal with eventually giving up.