Observer architecture

[samialabed]

Situations:

• Caching strategy:

  • Should cache:
  • False: upon [Miss] Punish. Happens only On GET (update?)
  • True: upon [Invalidate\Evict\Expire] Punish. Happens only on SET (update?) , evict, or expire.
  • True: upon [Hit] Reward. Happens only on GET.

• Eviction strategy:

  • Evict (key):
  • If Key is observed within (TTL). Punish, else reward.

• TTL estimation:

  • estimate

Questions:

• Should they all share the same fate. e.g. a key is decided that it should be cached, but next iteration, eviction strategy chose to evict it, but it was a hit, should one be rewarded the other punished, or share same fate (i.e. punish both).

[samialabed]

There is a lot of code duplication in cache_manager, and each strategy is calling observe with very similar arguments, making the code convoluted for no reason.

To make this framework generic for future work, make an observable interface.

And any class that implements it, it is up to it how it handles different observations (preferably has a separate method for each observation type)

The observation types can be limited to only 5: Hit, Miss, Invalidate, Set, Expire.