-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Advanced cache #6
Comments
|
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. |
Frankly, I am not a fan of the inclusion of adding a version tag to an interface. Could you describe this in more detail? |
I see it a lot in private APIs. If we use PSR-6 as a base and build on that. |
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 |
@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 :) |
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! |
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).
I honestly just don't understand this- like I can't grok the sentence. Can you reword/restate it again? |
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:
|
@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. |
1 similar comment
@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. |
PSR-6 has ways to add and retrieve data from the cache, that's kind of it's whole point? |
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. |
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.
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!
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);
}
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? |
I think my stab at humor went over your head :-P |
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. |
Pardon me if I declined to respond to your questions. It seems to me that you basically answered them yourself. |
Does that mean I covered all the "top heavy" bits? |
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. |
This is all about a cache on top of [RFC] Simpfilied cache.
Some points we should discuss:
Maybe it makes even more sense to call it StorageInterface, KeyValueStorage or something, because as I stated in the other Simplified Cache thread:
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.
The text was updated successfully, but these errors were encountered: