Xest has a bunch of modules to limit the number of server requests...
There are remains of previous attempts and various implementations.
These should be reviewed solidified behind a simpler concepts. Specifically we now use nebulex for cache with ttl... but in our usecase the best ttl is hard to guess... We could imagine splitting an "AdaptativeCache" library, where the ttl is computed dynamically (via a backoff algo or so...), with two implementations possible, one based on nebulex, and one without any external dependency...
In addition, for #18 there should be a possibility for the cache to decide to download data or not based on the data contents... as the last update time might be already contained in the cache...
Xest has a bunch of modules to limit the number of server requests... There are remains of previous attempts and various implementations.
These should be reviewed solidified behind a simpler concepts. Specifically we now use nebulex for cache with ttl... but in our usecase the best ttl is hard to guess... We could imagine splitting an "AdaptativeCache" library, where the ttl is computed dynamically (via a backoff algo or so...), with two implementations possible, one based on nebulex, and one without any external dependency...