[Cache] clear() and other unsupported actions

[Jeremy Lindblom]

Sam coded up some implementations that he shared on a previous thread. One of the comments he made was:

> I think the spec should address what to do if an underlying system doesn't support a feature. For example Zend doesn't support per item TTL and Phalcon doesn't support cache clearing.

Good question. What answer do we have for this?

[Crypto Compress]

It should be of no need to implement unused methods.
http://en.wikipedia.org/wiki/Interface_segregation_principle

[Robert Hafner]

There are a few ways to handle this.

For libraries than can, they should add the functionality to become feature complete. A "clear" function is pretty standard in most caching systems, so I would think in this case Phalcon should work to add that if they want their caching library to meet the interoperability standards.

Where the functionality can't be added it should be emulated. Doing this with TTL is pretty straight forward (on the backend, invisible to the user, the library can store a wrapper value that includes the original data as well as the metadata like the TTL). 

It should be noted that we did strip out a lot of what we originally wanted to put in this, with the idea that we would have a follow up set of interfaces that added additional functionality in. TTL was voted by the group as required for this version, so it's still here, but we will have follow ups that are far more optional due to the fact that not all systems will be able to support it. I guess what I'm saying is that I feel we've hit the minimal set of features we can reasonably expect to hit for this standard to actually be used by libraries looking for an interoperable caching system, and it shouldn't be too huge of a burden to match this.

Robert

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/2565f54b-59ee-4f96-a465-77649813e905%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Crypto Compress]

Am 28.03.2014 20:41, schrieb Robert Hafner:

There are a few ways to handle this.

For libraries than can, they should add the functionality to become feature complete. A "clear" function is pretty standard in most caching systems, so I would think in this case Phalcon should work to add that if they want their caching library to meet the interoperability standards.

Where the functionality can't be added it should be emulated. Doing this with TTL is pretty straight forward (on the backend, invisible to the user, the library can store a wrapper value that includes the original data as well as the metadata like the TTL). 

It should be noted that we did strip out a lot of what we originally wanted to put in this, with the idea that we would have a follow up set of interfaces that added additional functionality in. TTL was voted by the group as required for this version, so it's still here, but we will have follow ups that are far more optional due to the fact that not all systems will be able to support it. I guess what I'm saying is that I feel we've hit the minimal set of features we can reasonably expect to hit for this standard to actually be used by libraries looking for an interoperable caching system, and it shouldn't be too huge of a burden to match this.

Robert

Please forget my comment as i completely missed context. Robert nailed it.

[Jeremy Lindblom]

Sounds good Robert. Should we add something to the PSR that mentions feature emulation? Sam's comment wasn't that we should remove TTL or clear(), just that "the spec should address what to do if an underlying system doesn't support a feature".

--
Jeremy Lindblom
PHP Software Engineer at Amazon Web Services

Co-author of the AWS SDK for PHP

Co-organizer of the Seattle PHP User Group

@jeremeamia | http://webjeremy.com | https://github.com/jeremeamia

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5336FF83.4020103%40googlemail.com.

[Paul Dragoonis]

On Fri, Mar 28, 2014 at 7:41 PM, Robert Hafner <ted...@tedivm.com> wrote:

There are a few ways to handle this.

For libraries than can, they should add the functionality to become feature complete. A "clear" function is pretty standard in most caching systems, so I would think in this case Phalcon should work to add that if they want their caching library to meet the interoperability standards.

Where the functionality can't be added it should be emulated. Doing this with TTL is pretty straight forward (on the backend, invisible to the user, the library can store a wrapper value that includes the original data as well as the metadata like the TTL). 

It should be noted that we did strip out a lot of what we originally wanted to put in this, with the idea that we would have a follow up set of interfaces that added additional functionality in. TTL was voted by the group as required for this version, so it's still here, but we will have follow ups that are far more optional due to the fact that not all systems will be able to support it. I guess what I'm saying is that I feel we've hit the minimal set of features we can reasonably expect to hit for this standard to actually be used by libraries looking for an interoperable caching system, and it shouldn't be too huge of a burden to match this.

Thanks for backing things up again Robert.

The original question isn't about TTL support but any unsupported features

I wanted a supports() method, i.e: supports(CacheItem::SUPPORTS_TTL), or if(instanceOf CacheTTLInterface) - you get the point - how we achieve it isn't important, .

Stop to think for just a second, over time we'll have code floating about for PSR-Cache and PSR-Cache-Extended - we'll need a damn good way to identify if the $object we're dealing with supports features that could be in the normal or extended cache objects.

Can we take the original point and spin this into "feature detection" please?

 

Robert

On Mar 28, 2014, at 11:49 AM, Jeremy Lindblom <jerem...@gmail.com> wrote:

Sam coded up some implementations that he shared on a previous thread. One of the comments he made was:

> I think the spec should address what to do if an underlying system doesn't support a feature. For example Zend doesn't support per item TTL and Phalcon doesn't support cache clearing.

Good question. What answer do we have for this?

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/2565f54b-59ee-4f96-a465-77649813e905%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/6811387E-DB25-4A0C-9266-3D1A1492CA0B%40tedivm.com.

[Robert Hafner]

::ignores flamebait::

For optional features- such as things that come out in PSR-Cache-Extended- then we define feature sets with interfaces. For instance, a TaggableItemInterface would make sense if we introduced the optional feature of tagging. A StackableItemInterface would show that an Item supports the "stacks" feature.

For mandatory features this is unnecessary, and maybe even problematic. This group has said again and again that TTL and Clear are *required* for a caching system to be interoperable. Every Caching system that meets PSR-6 is going to support Clear and is going to support TTL. Jeremy forked the conversation to discuss what should be done for libraries and backend systems that can't meet those minimal requirements, and my response was that libraries should add it and if a backend doesn't support something it should be emulated. There's no point in defining a way to check whether it's capable of this functionality or not, because if the answer is "not" then it's not compliant with PSR-6 anyways.

Lets look at PSR-3, the Logger Interface, as an example. It's minimal requirements are the ability to pass along messages of the Emergency, Alert, Critical, Error, Warning, Notice, Info, Debug and Log event types, with both a message and a context. These are *minimal* requirements. If a Logging backend did not actually store the severity of the event then that can be emulated in the library by combining the severity and the message before storing it. In that case a minimal set of features were required, so no one had any qualms about the fact that there wasn't a "LoggerGenericInterface" and a separate "LoggerSeverityInterface". There was no point in  breaking out the two bits of functionality because they were the minimum needed for interoperability and therefore would always be present.

So, to solidly make sure your question is answered- for optional features there will be interfaces. For ones that are not optional that's a waste of time and adds confusion, as people may not realize they are optional.

Robert

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAKxcST-PCOfdanMauB010aF%2BR2TjdL1ft4Gh4QvV0zY8CYdK3Q%40mail.gmail.com.

[Paul Dragoonis]

On Mon, Mar 31, 2014 at 12:53 AM, Robert Hafner <ted...@tedivm.com> wrote:

::ignores flamebait::

For optional features- such as things that come out in PSR-Cache-Extended- then we define feature sets with interfaces. For instance, a TaggableItemInterface would make sense if we introduced the optional feature of tagging. A StackableItemInterface would show that an Item supports the "stacks" feature.

For mandatory features this is unnecessary, and maybe even problematic. This group has said again and again that TTL and Clear are *required* for a caching system to be interoperable. Every Caching system that meets PSR-6 is going to support Clear and is going to support TTL. Jeremy forked the conversation to discuss what should be done for libraries and backend systems that can't meet those minimal requirements, and my response was that libraries should add it and if a backend doesn't support something it should be emulated. There's no point in defining a way to check whether it's capable of this functionality or not, because if the answer is "not" then it's not compliant with PSR-6 anyways.

Lets look at PSR-3, the Logger Interface, as an example. It's minimal requirements are the ability to pass along messages of the Emergency, Alert, Critical, Error, Warning, Notice, Info, Debug and Log event types, with both a message and a context. These are *minimal* requirements. If a Logging backend did not actually store the severity of the event then that can be emulated in the library by combining the severity and the message before storing it. In that case a minimal set of features were required, so no one had any qualms about the fact that there wasn't a "LoggerGenericInterface" and a separate "LoggerSeverityInterface". There was no point in  breaking out the two bits of functionality because they were the minimum needed for interoperability and therefore would always be present.

So, to solidly make sure your question is answered- for optional features there will be interfaces. For ones that are not optional that's a waste of time and adds confusion, as people may not realize they are optional.

Robert

I'm not flamebaiting you! :-)

I'm happy to proceed with making TTL+Clear base PSR6 requirements and use interfaces going forward. We already discussed this approach and agreed upon it as the best solution.2

We could close this thread down I think and focus on newer topics instead of old ones. 

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/36214B19-3F2A-49C2-9D97-A7629AB98698%40tedivm.com.