If the request can be served from the cache, the actual cost is 20M cycles.
What is the caching criteria? If it’s time bound, what’s the cache expiry policy?
Is there a mechanism to call this from a client device? I imagine no, right? Since cycles have to be attached to the call? Don’t believe there’s a way to attach cycles from an agent, right?
Is there some prescription on whether these values should be further cached on the application side? I do understand that the answer to this is reliant on the answer to the first question and to the application’s tolerance towards stale data, but feel free to chime in
sorry for not coming back earlier. Somehow this thread was overlooked.
it used to be time bound initially. with this commit, the logic was changed to a simple LTU cache. so whether the cache is used or not depends on the provided timestamp and whether an exchange rate at given time has already been requested and is still retained in the LTU cache.
unfortunately it is not possible to attach cycles via an agent, correct.
I assume this depends on the needs of the application, whether you want to store historical data and make it accessible without having to call the XRC again.
I hope this helps and I expect @THLO to jump in if I said sth. wrong
@marc0olo is correct. It’s a simple LRU cache containing the last 1000 accessed rates. More precisely, it stores rates for any given base asset, the quote asset USDT, and a particular timestamp at a granularity of 1 minute.
It depends entirely on your application whether it makes sense to cache rates on the application side. If the rates are cached, you save yourself the trouble of making another call and paying the cycles cost. This approach is probably the right one if these rates are requested/used frequently.
On the other hand, if you only need some rates occasionally and they are hardly ever the same rates, then it might be easier to just request them each time. It depends on the usage of the XRC whether it can serve the rates from the cache, so you cannot rely on getting the low cost.
does that mean that I would always get the same price if it was already cached for a timestamp that is in the same minute window as another timestamp that I request the price for (even if that would potentially be different at given timestamp)?
An Asset is a record consisting of a symbol (for example, “ICP”) and a class (either Cryptocurrency or FiatCurrency). The full candid file can be found here. The optional timestamp in the request must be a UNIX timestamp in seconds when provided. If no timestamp is provided, the timestamp corresponding to the start of the current minute is used. Note that the granularity for requests is 1 minute, so seconds in a timestamp are ignored.
