Again, though, maybe I'm just missing the point here. Perhaps it would help to know what use case prompted Templar's development.
Again, though, maybe I'm just missing the point here. Perhaps it would help to know what use case prompted Templar's development.
Personally, I'd rather gain the necessary control through the request mechanisms, but for a quick-and-dirty solution, this would probably work pretty well.
Because a cache is best when it's populated often, it make sense to put that into a service that many different processes on different machines can use.
Everything within templar can be done by adding capabilities to client libraries, no argument. But most client libraries don't provide these capabilities in one programming language, let alone many of them. By having the functional available as a service, Templar provides these capabilities fairly transparently (and even more transparently in the future when there is per/host and per/url configuration).