package rxblocks
- Alphabetic
- Public
- All
Type Members
- class BlockHashPublisher extends SimplePublisher[EthHash, EthHash, BlockFilter]
- class BlockNumberNoFilterPublisher extends NoFilterPublisher[BigInt, BigInt]
- class ConfirmedLogPublisher extends Publisher[Recorded] with Parent[Recorded]
- class LogNoFilterPublisher extends NoFilterPublisher[Log, Log]
- abstract class NoFilterPublisher[T, S] extends Publisher[T] with Parent[T]
- abstract class SimpleProcessor[FROM, TO] extends Processor[FROM, TO] with Parent[TO]
- class SimpleSubscription[T] extends Subscription
- final class StubEventProcessor extends SimpleProcessor[Recorded, (SolidityEvent, Metadata)]
- class TestSubscriber extends Subscriber[Any]
-
class
BlockNumberPublisher extends SimplePublisher[BigInt, BigInt, Dummy.type]
- Annotations
- @deprecated
- Deprecated
(Since version 0.0.14) Use BlockNumberNoFilterPublisher, avoid iffily supported JSON-RPC filter ops.
-
class
LogPublisher extends SimplePublisher[Log, Log, Filter]
- Annotations
- @deprecated
- Deprecated
(Since version 0.0.14) Use LogNoFilterPublisher, avoid iffily supported JSON-RPC filter ops.
-
abstract
class
SimplePublisher[T, S, F <: Filter] extends Publisher[T] with Parent[T]
- Annotations
- @deprecated
- Deprecated
(Since version 0.0.14) Use NoFilterPublisher, avoid iffily supported JSON-RPC filter ops.
Value Members
- object BlockNumberPublisher
- object ConfirmedLogPublisher
- object LogNoFilterPublisher
- object LogPublisher
-
object
NoFilterPublisher
Unless the chosen filter supports a "fromBlock", there is no way to control precisely at what block a subscription begins.
Unless the chosen filter supports a "fromBlock", there is no way to control precisely at what block a subscription begins. A subscriber receives events "as they happen", and even if they subscribe very quickly after e.g. contract deployment, there can be no guarantee that they won't miss anything.
Fortunately, the most important filters (log filters) do support "fromBlock"
Unfortunately, it seems that clients don't pay attantion to an already-past "fromBlock" in the eth_getFilterChanges most implementations will rly upon.
T is the type that subscribers will receive. S is an intermediate type, that might be acquired then transformed to T. If this is not necessary, just define S to the same type as T. F is the Client.Filter type of the object usually used to specify the items that will get published. (Filter.Dummy can be acquired and left unused if no filter is necessary.)
- object SimpleProcessor
-
object
SimplePublisher
Unless the chosen filter supports a "fromBlock", there is no way to control precisely at what block a subscription begins.
Unless the chosen filter supports a "fromBlock", there is no way to control precisely at what block a subscription begins. A subscriber receives events "as they happen", and even if they subscribe very quickly after e.g. contract deployment, there can be no guarantee that they won't miss anything.
Fortunately, the most important filters (log filters) do support "fromBlock"
Unfortunately, it seems that clients don't pay attantion to an already-past "fromBlock" in the eth_getFilterChanges most implementations will rly upon.
T is the type that subscribers will receive. S is an intermediate type, that might be acquired then transformed to T. If this is not necessary, just define S to the same type as T. F is the Client.Filter type of the object usually used to specify the items that will get published. (Filter.Dummy can be acquired and left unused if no filter is necessary.)
- object SimpleSubscription