Currently the tryton client has simple cache feature for some hard-coded method (
get_keyword). This cache is invalidated by the logout.
Tryton could benefit from a more flexible cache system which could define what to cache and how long.
This cache could not reuse the standard HTTP feature because RPC requests are all
POST method for which cache does not make sense.
So we need to define our own cache protocol which should defines which parameters of the requests must be used as key of cache.
RPC object will use to store cache configuration. It will store a timedelta for the cache duration and a list of context keys from which the request depends.
On the answer of a request with cache information, the server will add in the headers the context keys and the duration.
The client will store in a size limited dictionary the result of a request if the cache headers are available and the expiration date. It will construct the dictionary key using the arguments and the context keys converted into a hashable object (currently client uses
On the next request, the client will first construct the key an check it exists in the cache and if it is still valid. Then it will use the cached result if possible or it will make the request to the server.
The possible methods that could be cached by default are:
Some on_change_with could also benefit from this cache like the
on_change_with_currency_digits's because they are often called with the same currency. But the client tries to group all the on_change* calls. So we will have to add on the fields definition that the on_change can be cached so the client will not group such query to benefit from the cache.
Some requests could push more result than the requested to pre-fill the cache with expected requests. But this will require to support HTTP/2.