Skip to main content
Skip table of contents

(v13) Notes on RDR and events

This page applies to Harlequin v13.1r0 and later; both Harlequin Core and Harlequin MultiRIP

Another way of describing the RDR and Event systems is via the pull and push metaphors.

RDR is a pull mechanism something requiring an entity can find it (or them) at a certain moment, but the RDR system provides no direct mechanism for managing the lifetime of an individual RDR. It is conceivable that an RDR might be de-registered between something successfully finding it and actually accessing the contents. This must be considered when designing a protocol using RDRs.

The worked example above of publishing API implementations as RDRs implicitly guarantees that the lifetime of an API found by a module will exceed that of the module itself. Also note that the RDR system is passive there is no automatic usage counting. Things that can disappear or change asynchronously, or that require lifetime management or long-term locking, should use the Event system.

The Event system is a push mechanism something that knows, has, or is about to remove something, can communicate immediately with interested parties with the possibility of those handlers refusing or modifying the intended behavior.

Having said that, a more accurate distinction is that the RDR system is passive, but the Event system active. Events can also be used to find things, much like the RDR system. The distinction is that handlers are actually called by the Event system. Providers of RDRs are never informed when those RDRs are found, delivered or used.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.