[RFC] Advanced cache

[marcj]

This is all about a cache on top of [RFC] Simpfilied cache.

Some points we should discuss:

1. Does it even make sense to create a advanced version, because we have already PSR6
2. If so 1., how could we do it without replacing PSR6 but add better stuff additional on top of it, so we don't have completely different PSRs but rather PSRs that complete each other.
3. Naming: I highly find it misleading to call it "AdvancedCacheInterface" or something. A better interface name describes its purpose so people could simply guess what methods are inside.

Maybe it makes even more sense to call it StorageInterface, KeyValueStorage or something, because as I stated in the other Simplified Cache thread:

Caching is there to jump over re-computation, nothing more. Not to change something on a key-value storage using increment/decrement, bulk-operation and stuff like that.

However, I think some functionality could make sense, like invalidation.

Let's please only discuss here caching interfaces that are different to [RFC] Simpfilied cache due to more methods/functionality.

[geggleto]

1. I think there some improvement that can be made on PSR-6.
2. Probably by creating a decorator around it.
3. Some sort of Adjective would make sense, likely not Advanced...There's always the option of adding a version tag to the namespace as well... But if we choose to use a Decorator, you could have CacheDecorator or something

[OddGreg]

Considering the purpose of this RFC, would it be valuable to assume that the simple interface has (for purposes of discussion) been clearly defined? That is, if the interest is in providing an advanced interface that leverages the simple interface. As a point of reference.

[OddGreg]

@geggleto

Frankly, I am not a fan of the inclusion of adding a version tag to an interface. Could you describe this in more detail?

[geggleto]

@OddGreg

\v1\CacheInterface

\v2\CacheInterface

\v3\CacheInterface

I see it a lot in private APIs.

If we use PSR-6 as a base and build on that.

[marcj]

I agree with @OddGreg: I also really don't like version numbers in official interfaces :)

@OddGreg I don't think its spec is done. Maybe we should wait a bit to discuss this advanced in more detail.

[OddGreg]

@geggleto

Allow me to be direct in saying no. Whether or not some authors have decided to do such a thing, I think it represents unclear and/or provisional thinking. Is that the intent?

@marcj
I agree with you on that point.

[icambridge]

I think the answer to 1. is yes. PSR-6 doesn't have the server pool section it's literally as far as I can tell a set of interfaces for the items and handling the cache but not for querying it.

I think the answer to 2. is to use the PSR-6 interface for items being stored/fetched/etc and only work on the cache "Pool" interface.

And I think the answer to 3. Is to create a set of interfaces instead of one holy grail interface. So MultiCacheInterface, CacheExistsInterface, etc.

[geggleto]

@OddGreg A lot of it has to do with Backwards Compatibility. Like I said I see it a lot in using APIs. Seen it a few times in the wild when it comes to libraries. There are justifiable use cases. Whether its applicable here, that's for the community to say.

That being said @icambridge has a very nice solution to the problem :)

[OddGreg]

@geggleto

Yes, I understand the value of versioning in particular cases. I just don't think now is the time to overthink the situation, but rather to go forward with the specification without resorting to worrying about BC issues. Like the frog said to the fish: Spawn? We haven't had dinner yet!

[tedivm]

PSR-6 was designed to be extendable. Adding in support for things like Namespacing and Tags, for example, is really simple.

It should also be simple to turn any PSR-6 library into a "Simple Cache" (I don't even need to see what the simple cache's final interface looks like to know that).

PSR-6 doesn't have the server pool section it's literally as far as I can tell a set of interfaces for the items and handling the cache but not for querying it.

I honestly just don't understand this- like I can't grok the sentence. Can you reword/restate it again?

[OddGreg]

@tedivm

Now you've gone and done it. Made me revisit the PSR-6 specification.

Edit: I'll just drop this from the PSR-6 meta document here:

3.1 Goals

• A common interface for basic and intermediate-level caching needs.
• A clear mechanism for extending the specification to support advanced features, both by future PSRs or by individual implementations. This mechanism must allow for multiple independent extensions without collision.

[icambridge]

@tedivm well what I mean is the PSR-6 specs doesn't appear to have an interface to deal with fetching data from a cache or adding to a cache.

[icambridge]

@tedivm well what I mean is the PSR-6 specs doesn't appear to have an interface to deal with fetching data from a cache or adding to a cache.

[tedivm]

PSR-6 has ways to add and retrieve data from the cache, that's kind of it's whole point?

[OddGreg]

I may be foggy from a long night so disregard if this is out in left field -- but, are we really making the statement that PSR-6 is a wonderful thing that shines light up the unicorn's posterior? In my humble and tangential opinion, it's over-engineered and top heavy.

[tedivm]

I don't see any mention of unicorn asses in any of the above comments.

However, it's going to be very difficult to answer question one of this topic without talking about the good and bad portions of PSR-6.

1. Does it even make sense to create a advanced version, because we have already PSR6
2. If so 1., how could we do it without replacing PSR6 but add better stuff additional on top of it, so we don't have completely different PSRs but rather PSRs that complete each other.

So, since the idea is to talk about these topics, can I ask what you consider to be over engineered and top heavy?

interface CacheItemInterface
{
    public function getKey();
    public function get();
    public function isHit();
    public function set($value);
    public function expiresAt($expiration);
    public function expiresAfter($time);
}

interface CacheItemPoolInterface
{
    public function getItem($key);
    public function getItems(array $keys = array());
    public function hasItem($key);
    public function clear();
    public function deleteItem($key);
    public function deleteItems(array $keys);
    public function save(CacheItemInterface $item);
    public function saveDeferred(CacheItemInterface $item);
    public function commit();
}

I'll start!

1. The support for "multiple" operations is somewhat awkward. Without supporting "multiple" operations the getItems, deleteItems, saveDeferred, and commit functions aren't needed.
2. Supporting the "expiresAt" and "expiresAfter" is not really all that useful, especially in cases where people don't use a TTL anyways.

Stripping out those functions leaves this-

interface CacheItemInterface
{
    public function getKey();
    public function get();
    public function isHit();
    public function set($value);
}

interface CacheItemPoolInterface
{
    public function getItem($key);
    public function hasItem($key);
    public function clear();
    public function deleteItem($key);
    public function save(CacheItemInterface $item);
}

1. Looking at what remains the only thing that I see which is somewhat questionable is that the interface still requires people to save the Item back into the Pool to push it to the cache. Without the multiple operations this makes less sense. (note this should be issue three but markdown is failing me).

So punting issue three for a moment, does removing the stuff from issues one and two make this set of interfaces less "top heavy"? If not what other issues are present?

[tedivm]

I think my stab at humor went over your head :-P

[OddGreg]

@tedivm

I got it -- delayed a bit by brainfog. Which is why I deleted my last comment. :) Nobody's perfect. But I do think you are going in the right direction with your post.

[OddGreg]

@tedivm

Pardon me if I declined to respond to your questions. It seems to me that you basically answered them yourself.

[tedivm]

Does that mean I covered all the "top heavy" bits?

[OddGreg]

I'd say so. But I have a caveat: like so many people, I worked until 6am and at the moment, my remaining programming neuron is on strike.