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
Protocol Metrics are a new alternative design to nested-function parsed parameter metrics.
Instead of allowing arbitrary metric functions to enclose metrics, protocol metrics will be configured with a fixed set of 'core parameters' that when values are passed to them (as if the metric itself was a function name), they are at request time metric-built/transformed into a variation on the base metric.
The novel concept is a Protocol (formerly called a named signal), which represents a transformation that the system is configured to be able to apply, with an associated contract name (representing the type of the transform) and core parameter(the api named parameter that signals that the protocol should be applied.
In general, protocols and the metric functions that they enclose are expected to be immutable and not close over any interesting state or have any dependencies on metrics instances.
Similarly, it's going to generally be good practice to have a single Protocol implementation used in a system for a given contract name and a single Protocol associated with any given 'core parameter'.
Protocols are connected to Metrics via a 'ProtocolSupport' object, also immutable objects, containing a map of protocols that a metric accepts and a blacklist indicating which protocol contracts should be forbidden to any metric built on top of this metric. Example: A reaggregated metric (built by AggregationAverageMaker) should never be subjected to the 'reaggregation' protocol, nor should any metric built (say by apply arithmetic operations) upon it.
The text was updated successfully, but these errors were encountered:
Protocol Metrics are a new alternative design to nested-function parsed parameter metrics.
Instead of allowing arbitrary metric functions to enclose metrics, protocol metrics will be configured with a fixed set of 'core parameters' that when values are passed to them (as if the metric itself was a function name), they are at request time metric-built/transformed into a variation on the base metric.
The novel concept is a Protocol (formerly called a named signal), which represents a transformation that the system is configured to be able to apply, with an associated contract name (representing the type of the transform) and core parameter(the api named parameter that signals that the protocol should be applied.
In general, protocols and the metric functions that they enclose are expected to be immutable and not close over any interesting state or have any dependencies on metrics instances.
Similarly, it's going to generally be good practice to have a single Protocol implementation used in a system for a given contract name and a single Protocol associated with any given 'core parameter'.
Protocols are connected to Metrics via a 'ProtocolSupport' object, also immutable objects, containing a map of protocols that a metric accepts and a blacklist indicating which protocol contracts should be forbidden to any metric built on top of this metric. Example: A reaggregated metric (built by AggregationAverageMaker) should never be subjected to the 'reaggregation' protocol, nor should any metric built (say by apply arithmetic operations) upon it.
The text was updated successfully, but these errors were encountered: