Introduce a cache storage SPI

[tsegismont]

When the cache is enabled, cached content is stored on heap memory.

Users should be able to choose between different storage implementations.

[wzy1935]

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.

[tsegismont]

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, not Resource 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).

[wzy1935]

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.

[tsegismont]

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.