Open tsegismont opened 5 months ago
For this one, my current thought is this:
interface Cache {
Future<Void> put(String key, String value);
Future<String> get(String key);
Future<Void> remove(String key);
Future<Void> removeEldest();
Future<Integer> size();
}
Here I use String
as the value, not Resource
because I think it might be better if we do the en/decoding for the users.
Another thing I'm worrying about is whether the output parameter should be wrapped with Future
. For example, vertx-redis-client uses async functions for its APIs.
For this one, my current thought is this:
interface Cache { Future<Void> put(String key, String value); Future<String> get(String key); Future<Void> remove(String key); Future<Void> removeEldest(); Future<Integer> size(); }
I think the removeEldest
method isn't necessary in the interface. It's an implementation detail.
Here I use
String
as the value, notResource
because I think it might be better if we do the en/decoding for the users.
What do you mean with encoding/decoding? What would be the benefit?
Another thing I'm worrying about is whether the output parameter should be wrapped with
Future
. For example, vertx-redis-client uses async functions for its APIs.
Indeed, we should consider every operation on the cache may be asynchronous (not only for Redis, we could imagine an implementation with Infinispan, Hazelcast, ... etc).
What do you mean with encoding/decoding? What would be the benefit?
The encoding/decoding refers to how to transform data between Resource
objects to raw bytes in order to store them (serialization). If we do the serialization for the user (meaning that the parameter is either String
or byte[]
), the benefit would be that the SPI would be easier to implement for the user since storing bytes or strings is easy; If not (meaning that the parameter is Resource
), the user would have more control on serialization, on the other hand. So that's a design option that I'm not sure.
We don't have any other choice than caching the Resource
object as value, do we? Because we need not only the cached response but all the metadata.
Regarding how to convert this to bytes or vert.x Buffer
, take a look at Vert.x Web SessionStore
SPI and the Sesssion
implementation. In Vert.x core we have the ClusterSerializable
that provides a contract for serializing to or deserializing from a Buffer
.
When the cache is enabled, cached content is stored on heap memory.
Users should be able to choose between different storage implementations.