On Jan 27, 2011, at 8:54 PM, Heiko Braun wrote:
On the API level this separation highlights that metrics run under
different performance considerations
and different semantics apply in general. It should not be intermingled with config
data.
Anything we build atop of that (caching, aggregation, etc) would clearly benefit from a
distinction build into the API
right from the beginning.
Another thing that just came to my mind, with regard to semantics:
Will metrics be 'pulled' from a subsystem component with every request,
or is a subsystem component forced to 'push' state changes to domain runtime
state?
The later would force the domain store these values redundantly (and stale)
whereas the 'pull' semantic would more work like a snapshot of the state the each
subsystem manages on it's own.
IMO this further justifies a separation of those two aspects.
Ike