PSR Cache - Ready for Vote? What's Remaining?

[Paul Dragoonis]

Hey all,

The proposal is a result of the review of many existing PHP cache systems. 

To name a few: Stash, DoctrineCache, PHPRedis Extension, Memcached Extension, PPI\Cache.

The cache proposal hasn't changed in a few months now and I'm curious to know what's missing, I'd like people to actually contribute to the proposal with any changes they feel are necessary rather than just giving their two cents on the mailing list.

If nobody has any changes to make then I'm going to call up a vote on this within the next few weeks.

Thanks all and lets be productive and pragmatic to bring closure to a proposal that's been open for a long time now.

https://github.com/dragoonis/fig-standards/blob/master/proposed/psr-cache.md

Regards,

Paul Dragoonis

[Paul Jones]

On May 15, 2013, at 6:47 PM, Paul Dragoonis wrote:

> If nobody has any changes to make then I'm going to call up a vote on this within the next few weeks.

One addition: there needs to be a survey of the existing member cache systems that shows how they currently operate, similar to how a survey was done for PSR-1, PSR-2, and PSR-3.

If the proposed cache ends up being wildly different from those, then I'd suggest the proposal would need to be modified (but wait and see -- it might be close indeed).


-- pmj

[Paul Dragoonis]

Can you outline the criteria of this survey so that it may be conducted?

--
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.

For more options, visit https://groups.google.com/groups/opt_out.

[Paul Jones]

On May 15, 2013, at 7:11 PM, Paul Dragoonis wrote:

> Can you outline the criteria of this survey so that it may be conducted?

A start point is the class breakdowns and the method names for various operations, perhaps along with the signatures for those methods. That way we can see if there are commonalities between them that we might capitalize on.


-- pmj

[Paul Dragoonis]

Apart from the methods, what else?

-- pmj

[Paul Jones]

On May 15, 2013, at 7:17 PM, Paul Dragoonis wrote:

> Apart from the methods, what else?

I think it'll become obvious what the next step is (if any) after that.


-- pmj

[Amy Stephen]

Paul -

I've had this ready to go, waiting for final approval, for months. The only minor suggestion I had was returning $this, instead of true or false, as per my suggestion https://github.com/php-fig/fig-standards/pull/96 but it is not a show stopper. IMO, it's fine.

Paul Jones - IIRC, you did a survey shortly before concluding PSR-tabs-vs-spaces, I believe as a recommendation by me. Yes? Is that a requirement now? You have to admit, the idea that this would have to start over with a survey now, after all this time and work has been done is, at minimum, potentially discouraging for future efforts. If this goes another year and gets to this point can someone else require something else? Hope you understand my point and hear it in the positive way intended.

If PSR-X has taught us anything, we can adapt later if we need to. Right?

IMO, Sail on, sailor. Rock on. Let this go out to the world where it can do good things, and so forth and so on, etc., and peace and love for all. Unless you don't like that kind of thing...

Note: "You" is not intended to point at anyone. Goofy ended intended to defuse any frustration that might be lingering from my comments, nothing else.

[Florin Patan]

During the talks we've had a while back, I'm not sure if it was in my proposal or in Paul's one, it was concluded that we don't really need to do that if we are doing something new / better.

If you are still going to ask for this kind of survey, then in all honesty, I think this should be specified somewhere that a survey like this is needed.

Also, since this contains bits from my proposal, mostly the function names and parameters are the same as in Doctrine/Cache but I'm not sure about Zend/Cache.

But then again, maybe you should make a demo survey on how this should look like because to me it feels pointless to have a table where I'm mapping the methods from X/Cache to PSR/Cache.

Thanks for your time,

Florin

[Marco Pivetta]

Hey Paul!

Didn't go through it in detail, but I am wondering why this proposal defines a `CacheAwareInterface`: I personally think this encourages setter injection (bad, again IMO) and doesn't have to do with the cache itself rather than with its consumers.

Consumers decide on their own how to consume a PSR cache, they don't need an interface with a setter.

Yes, the suggestion is to remove that one interface :)

Marco Pivetta

http://twitter.com/Ocramius     

http://ocramius.github.com/

[Bernhard Schussek]

2013/5/16 Marco Pivetta <ocra...@gmail.com>

Yes, the suggestion is to remove that one interface :)

+1

Cheers,

Bernhard

--

Bernhard Schussek
Blog: http://webmozarts.com
Twitter: http://twitter.com/webmozart

2013/5/16 Marco Pivetta <ocra...@gmail.com>

[Evert Pot]

On 16 mei 2013, at 09:51, Bernhard Schussek <bsch...@gmail.com> wrote:

2013/5/16 Marco Pivetta <ocra...@gmail.com>

Yes, the suggestion is to remove that one interface :)

+1

I would want to concur as well. Lets not continue that terrible pattern..

[Paul Dragoonis]

Hey Marco,

We have it for Psr\Log - https://github.com/php-fig/log/blob/master/Psr/Log/LoggerAwareInterface.php

We should remain consistent.

--

[Marco Pivetta]

On 16 May 2013 13:54, Paul Dragoonis <drag...@gmail.com> wrote:

Hey Marco,

We have it for Psr\Log - https://github.com/php-fig/log/blob/master/Psr/Log/LoggerAwareInterface.php

We should remain consistent.

No, it's not about being consistent - it's about avoiding very bad practices in my opinion. I totally missed the one of the logger, would have -1ed  that one too.

[Evert Pot]

On May 16, 2013, at 1:00 PM, Marco Pivetta <ocra...@gmail.com> wrote:

> On 16 May 2013 13:54, Paul Dragoonis <drag...@gmail.com> wrote:
> Hey Marco,
>
> We have it for Psr\Log - https://github.com/php-fig/log/blob/master/Psr/Log/LoggerAwareInterface.php
>
> We should remain consistent.
>
>
> No, it's not about being consistent - it's about avoiding very bad practices in my opinion. I totally missed the one of the logger, would have -1ed that one too.

Absolutely the same here :) Lets kill this before it does become the default.

Evert

[Donald Gilbert]

What is, in your opinion, the bad practice being followed here? Setter injection? If so, I would disagree with you there and say that it is neither bad nor good. It's an optional type of implementation and a completely valid approach. 

[Marco Pivetta]

On 16 May 2013 16:21, Donald Gilbert <dilber...@gmail.com> wrote:

What is, in your opinion, the bad practice being followed here? Setter injection? If so, I would disagree with you there and say that it is neither bad nor good. It's an optional type of implementation and a completely valid approach. 

@Donald since it's optional, it doesn't need an interface to be implemented to be PSR-X compliant, therefore remove the interface.

And yes, it's a bad practice.
At least half of my debugging time goes in missed setter injection somewhere, not to mention answering questions by users (in the communities I follow) who apply the initializer pattern in wrong ways or expect it to be magic.
Also, cache usually isn't not a soft dependency (we use null caches to achieve that).

[Amy Stephen]

See, Marco, this is exactly why I said I need to study all of your posts. =)

(I'm of Don's thinking, but your comments did twist the wires in my brain and my practices will change, as a result.)

Paul - I think go ahead and remove it. I don't use either in the log or cache. I agree with your consistency comment and I know exactly why it's there. But, if this is better then Cache will serve as a better guide for the next PSR. I suspect each time, it'll get better.

I'd pull it out. Problem solved. Next?

[Donald Gilbert]

Well since it is an optional as well as valid way to implement, in my opinion it doesn't need to be removed. But, I don't make the decisions, I just offer opinions. :)

[Paul Jones]

On May 15, 2013, at 9:30 PM, Amy Stephen wrote:

> Paul Jones - IIRC, you did a survey shortly before concluding PSR-tabs-vs-spaces, I believe as a recommendation by me. Yes?

Yes; it was your recommendation, and it was truly inspired. We are here to codify common practices between the member projects; what better way to determine those commonalities than by doing a review and report (aka survey) of those practices? It was such a good idea that I've felt the need to insist on it for practically everything since. Even the HTTP proposer took it to heart (and that proposal it what I hope to turn back toward soon).

> Is that a requirement now?

Not a requirement yet, but I will argue that It's A Really Good Idea. If we are here to codify common practices, and not just write up new stuff from scratch, then we need to determine what those practices are.

> You have to admit, the idea that this would have to start over with a survey now, after all this time and work has been done is, at minimum, potentially discouraging for future efforts. If this goes another year and gets to this point can someone else require something else? Hope you understand my point and hear it in the positive way intended.

Yes, I agree a lot of work has been done. But "work being done" has never so far in this group been a reason to say "well go ahead and go with it." It has to be the *right* work.

Even PSR-X was not without a survey of sorts; note that Joomla, Drupal, Pyro, and even Aura had variations of the proposal under vote. With the caching proposal, *nobody* has a variation of it in place yet.


-- pmj

[Amy Stephen]

Oh sure, be charming, Paul. Like that is playing fair!

Now, here's the difference. First, I think a survey is good if for no other reason than than to begin building support for the PSR and start building involvement. But, it has little use at the end of the project, although it's tough to argue with the notion that FIG should vote something of little value or quality in on the basis that someone worked hard. I agree on that.

In your case, a survey was helpful because you were being inundated with the tabs versus spaces crowd and I hoped it might save you.

I'm a little worried about creating an impression that member projects do not have to pay attention, that mechanisms are in place to make certain solutions will easily work for them. And, frankly, I would expect you to push back on such a notion, too.

So, I took a quick first stab at simply identifying libraries. Maybe if we can confirm this is the scope of cache libraries? Then, if there are so few participating, maybe Paul can focus on their feedback, involvement?

Or, other ideas. Going out for a while, will check back later to see if I can help.


Member projects without cache class:

1. Amazon Web Services SDK
2. Apache log4php
3. Assetic
4. Buzz
5. Aura Project - no?
6. eZ Publish - couldn't find the source
7. Jackalope
8. Packagist
9. PEAR, PEAR2
10. phpBB
11. phpDocumentor
12. PPI, PPI2 - probably waiting for standard ? https://github.com/ppi/cache-module
13. Propel, Propel 2
14. SabreDAV
15. SugarCRM - ???
16. Symfony, Symfony2 - don't have one
17. TYPO3 - couldn't find it
18. Zikula looks like they might be using Doctrine's cache?

These are links to member cache that I was able to quickly find:

1. Agavi http://trac.agavi.org/browser/trunk/src/config/AgaviConfigCache.class.php
2. CakePHP, CakePHP 2 http://book.cakephp.org/2.0/en/core-libraries/caching.html
3. Doctrine, Doctrine2, et al. http://docs.doctrine-project.org/en/2.0.x/reference/caching.html
4. Drupal http://api.drupal.org/api/drupal/includes!cache.inc/interface/DrupalCacheInterface/7
5. Joomla - https://github.com/joomla/joomla-framework-cache (implemented)
6. Laravel - https://github.com/illuminate/cache/blob/master/StoreInterface.php
7. Lithium https://github.com/UnionOfRAD/lithium/blob/master/storage/Cache.php
8. Packagist n/a
9. PyroCMS https://github.com/pyrocms/pyrocms/blob/b0cc973f7abe2285e559105cea6a69a3579ed101/system/codeigniter/libraries/Cache/Cache.php
10. Zend Framework 2 https://github.com/zendframework/Component_ZendCache

[Beau Simensen]

On Thursday, May 16, 2013 10:30:27 AM UTC-5, pmjones wrote:

With the caching proposal, *nobody* has a variation of it in place yet.

To be fair, Robert implemented his original Cache proposal in Stash a year ago.

https://github.com/tedivm/Stash/pull/30

With the talk of having reference implementations prior to a proposal being accepted, this seems like a good case for that. That proposal has been implemented and been in use by an actual standalone cache library for at least a year now.

It would be interesting to see what has changed on the proposal since then and whether or not the actual implementation is still in compliance with the proposal.

It is a bummer that Robert has not returned to discuss his proposal in more detail again. I still hope that he can and that his proposal is still on the table as a viable option for the members to vote on. I still think that Evert's original proposal is probably closer to what most member projects are already doing. A survey may prove me wrong, though.

If most of the member projects are not doing it right, and we have to keep codifying common practices as our primary goal, let's work on convergence and moving everyone toward better practices and then codify them.

Cache is hard. If we go for a lowest common denominator solution, or even a compromise solution based on a survey of the member projects, we might be better off not standardizing on cache at all.

Do it right or don't standardize it. I say this even after all of the work I've put in on three of the four cache proposals.

[Paul Jones]

On May 16, 2013, at 2:03 PM, Amy Stephen wrote:

> I think a survey is good if for no other reason than than to begin building support for the PSR and start building involvement. But, it has little use at the end of the project,

I would argue that the survey is *best* at the beginning of the project, because it will help lead efforts in the direction of "codifying commonalities between member projects." If the survey comes at the end, then it is still useful, because it tells us how much of the proposal is brand new stuff that doesn't exist yet in a member implementation anywhere. (Per Larry Garfield's survey, the leading goal of the group is to codify what exists, and only secondarily to make new things that don't exist yet, which still makes the survey useful.)

> I'm a little worried about creating an impression that member projects do not have to pay attention, that mechanisms are in place to make certain solutions will easily work for them.

On the contrary, I think member project representatives will pay *more* attention when they see their project names in discussions that compare and contrast their approaches. Indeed, I think it will drive their participation; everyone wants to make sure their way of doing things is fairly represented.

> So, I took a quick first stab at simply identifying libraries. Maybe if we can confirm this is the scope of cache libraries? Then, if there are so few participating, maybe Paul can focus on their feedback, involvement?
>
> Or, other ideas. Going out for a while, will check back later to see if I can help.
>
> Member projects without cache class:

(FWIW, I googled the project name and "cache" for the following; the best way to determine, though, is to grab the codebase for each project and grep for "cache").

> • Aura Project - no?

Aura does not, but Solar does: <http://solarphp.com/apidoc/package.Solar_Cache>


> • eZ Publish - couldn't find the source

Source appears to be at <http://svn.ez.no/svn/ezcomponents/trunk/Cache>


> • PEAR, PEAR2

PEAR definitely has a caching package; two, in fact:

- http://pear.php.net/package/Cache
- http://pear.php.net/package/Cache_Lite


> • phpBB

I *think* this is the phpBB cache system, but it might be an add-on: <https://wiki.phpbb.com/Cache>

> • Propel, Propel 2

Propel 1 at least has some sort of caching system: <http://propelorm.org/behaviors/query-cache.html>


> • SugarCRM - ???

This document indicates they have one: <http://developers.sugarcrm.com/wordpress/2011/08/30/deciphering-the-sugarcrm-cache-directory/>


> • Symfony, Symfony2 - don't have one

Symfony 1 had caching, indicated by this document: <http://symfony.com/legacy/doc/book/1_0/en/12-Caching>


> • TYPO3 - couldn't find it

Seems to have one: <http://wiki.typo3.org/Caching_framework>

> These are links to member cache that I was able to quickly find:
> • Agavi http://trac.agavi.org/browser/trunk/src/config/AgaviConfigCache.class.php
> • CakePHP, CakePHP 2 http://book.cakephp.org/2.0/en/core-libraries/caching.html
> • Doctrine, Doctrine2, et al. http://docs.doctrine-project.org/en/2.0.x/reference/caching.html
> • Drupal http://api.drupal.org/api/drupal/includes!cache.inc/interface/DrupalCacheInterface/7
> • Joomla - https://github.com/joomla/joomla-framework-cache (implemented)
> • Laravel - https://github.com/illuminate/cache/blob/master/StoreInterface.php
> • Lithium https://github.com/UnionOfRAD/lithium/blob/master/storage/Cache.php
> • Packagist n/a
> • PyroCMS https://github.com/pyrocms/pyrocms/blob/b0cc973f7abe2285e559105cea6a69a3579ed101/system/codeigniter/libraries/Cache/Cache.php
> • Zend Framework 2 https://github.com/zendframework/Component_ZendCache

/me nods

It appears that a significant number (a majority?) of the voting member projects have a cache implementation of some type. Reviewing those implementations, determining their commonalities, and identifying their weak points (if any) should be the first order for any caching proposal.


-- pmj

[Paul Jones]

On May 16, 2013, at 2:05 PM, Beau Simensen wrote:

> On Thursday, May 16, 2013 10:30:27 AM UTC-5, pmjones wrote:
> With the caching proposal, *nobody* has a variation of it in place yet.
>
> To be fair, Robert implemented his original Cache proposal in Stash a year ago.
>
> https://github.com/tedivm/Stash/pull/30

My apologies for the ambiguous wording; I should have been more clear: "no voting members" have a variation of it in place yet.

> I still think that Evert's original proposal is probably closer to what most member projects are already doing. A survey may prove me wrong, though.

Or it may prove you more right than you know; if the proposal is shown to be close to what is already in use, then hooray!

> If most of the member projects are not doing it right, and we have to keep codifying common practices as our primary goal, let's work on convergence and moving everyone toward better practices and then codify them.

I completely agree on this point. The idea is to find the commonalities, and then identify the weaknesses (if any). "Doing it right" is a *little* subjective, but I bet that obvious flaws will be, well, obvious. ;-)


-- pmj

[Paul Jones]

On May 16, 2013, at 2:05 PM, Beau Simensen wrote:

> On Thursday, May 16, 2013 10:30:27 AM UTC-5, pmjones wrote:
> With the caching proposal, *nobody* has a variation of it in place yet.
>
> To be fair, Robert implemented his original Cache proposal in Stash a year ago.
>
> https://github.com/tedivm/Stash/pull/30

My apologies for the ambiguous wording; I should have been more clear: "no voting members" have a variation of it in place yet.

> I still think that Evert's original proposal is probably closer to what most member projects are already doing. A survey may prove me wrong, though.

Or it may prove you more right than you know; if the proposal is shown to be close to what is already in use, then hooray!

> If most of the member projects are not doing it right, and we have to keep codifying common practices as our primary goal, let's work on convergence and moving everyone toward better practices and then codify them.

[Phil Sturgeon]

Ignore PyroCMS from that list. The cache you are referring to there Amy is the CodeIgniter Cache driver, which is a joke.

We rock our own Cache driver in 2.3/develop which will happily switch to using PSR\Cache whatever it ends up being.

[Jason Judge]

On Thursday, 16 May 2013 21:18:32 UTC+1, pmjones wrote:

...

>         • SugarCRM - ???

This document indicates they have one: <http://developers.sugarcrm.com/wordpress/2011/08/30/deciphering-the-sugarcrm-cache-directory/>

Don't count on it - "cache" can also be just a name ;-) The cache folder on SugarCRM is an area the application puts uploaded documents, emails, and "compiled" code that is executed in-situ. The closest to a cache in there are the smarty templates, and processed theme assets. I can think of a few instances where a generic cache would be useful in SugarCRM (and am using one through data retrieved from the REST interface) but in general there is not much *generic* caching going on. That can certainly change, and I do hope it does. I've expanded on that article a little here, as much to remind myself what can be deleted in the cache folder and what must never be touched:

<http://academe.co.uk/2012/06/sugarcrm-cache-directory-it-is-not-a-cache-directory/>

I'm not sure anything SugarCRM puts in the cache folder is the kind of thing this cache PSR is trying to tackle.

-- Jason

[Paul Jones]

On May 16, 2013, at 4:23 PM, Jason Judge wrote:

>
>
> On Thursday, 16 May 2013 21:18:32 UTC+1, pmjones wrote:
>
> ...
>
> > • SugarCRM - ???
>
> This document indicates they have one: <http://developers.sugarcrm.com/wordpress/2011/08/30/deciphering-the-sugarcrm-cache-directory/>
>
>
> Don't count on it - "cache" can also be just a name ;-)

Fair point -- my examination was cursory as best. Like I said, the real process would be to download the codebase then grep it for "cache" and look at the results.


-- pmj

[Larry Garfield]

Paul, I remind you that the last survey I ran showed a preference among
both members and non-members for "cautiously forward looking", not just
"codify what we're already doing". So even a soft "there must always be
a survey" policy would be inconsistent with the sentiment of the group.
We're here to improve project interoperability; sometimes that means
solving a common problem, not just waiting for a bunch of people to
solve it and stamping it.

You may disagree, but the data says you're in the minority.

--Larry Garfield

[Hari K T]

A survey is good I think. But no one ask will force you to make it according to survey.

As mentioned many projects may be doing things wrong. But for people to get a quicker look it seems good so can think beyond ?

This is a work on 8 , which means we will never jumb from the circle. Let us quickly do a survey with the projects who have cache.

Hari K T

http://harikt.com , https://github.com/auraphp

--
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+unsubscribe@googlegroups.com.

[Robert Hafner]

> My apologies for the ambiguous wording; I should have been more clear: "no voting members" have a variation of it in place yet.

Nice to know that all the work I've put into this caching proposal- including work lifted from my proposal and placed into the one you're talking about passing- means nothing because I wasn't voted into the inner circle.

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.

[Larry Garfield]

On 05/16/2013 02:05 PM, Beau Simensen wrote:
> Do it right or don't standardize it. I say this even after all of the
> work I've put in on three of the four cache proposals.

+1 so hard!

--Larry Garfield

[Larry Garfield]

I disagree entirely.  There's nothing wrong with setter injection if used correctly.  It can actually help with automation quite a bit if you have a factory or DI container that is spawning objects.  It can check if an object implements an "aware" interface, and if so give it what it needs.  Symfony is doing that in a few places, Drupal is doing it in a few places, PSR-3 has it...  Keep it in.

--Larry Garfield

[Larry Garfield]

On 05/15/2013 06:47 PM, Paul Dragoonis wrote:
> Hey all,
>
> The proposal is a result of the review of many existing PHP cache
> systems.
>
> To name a few: Stash, DoctrineCache, PHPRedis Extension, Memcached
> Extension, PPI\Cache.
>
> The cache proposal hasn't changed in a few months now and I'm curious
> to know what's missing, I'd like people to actually contribute to the
> proposal with any changes they feel are necessary rather than just
> giving their two cents on the mailing list.

>
> If nobody has any changes to make then I'm going to call up a vote on
> this within the next few weeks.
>

> Thanks all and lets be productive and pragmatic to bring closure to a
> proposal that's been open for a long time now.
>
> https://github.com/dragoonis/fig-standards/blob/master/proposed/psr-cache.md
>
> Regards,
> Paul Dragoonis

I had proposed a bunch of language-tightening for the interfaces here,
which never seemed to get any feedback:

https://github.com/Crell/fig-standards/commit/6172c896c452e399bbcb9ead199cdfcfe2efed82

(I tried to make a PR but got bitten by the too-many-repos problem.
Grrr...) It looks like at least some of those issues noted are still
outstanding.

Also, there are still some too-soft language like "The TTL is normally
defined by an integer representing time in seconds." No, not normally.
If it's not in seconds you're in violation of the spec. :-)

The cache key format language is also far too soft. I don't know why it
changed from defining a minimum set of legal values and turned into a
casual recommendation, but that's a bad change. It should be a clear,
required definition that up-to-32-character ASCCI alphanumerics MUST
always be valid cache keys so that there's at least a LCD legal key value.

Linking to gists as examples is probably not wise either. There have
been cases of gists going missing, which would be decidedly not good.

--Larry Garfield

[Marco Pivetta]

On 17 May 2013 04:24, Larry Garfield <la...@garfieldtech.com> wrote:

On 05/16/2013 09:25 AM, Marco Pivetta wrote:

And yes, it's a bad practice.
At least half of my debugging time goes in missed setter injection somewhere, not to mention answering questions by users (in the communities I follow) who apply the initializer pattern in wrong ways or expect it to be magic.
Also, cache usually isn't not a soft dependency (we use null caches to achieve that).

I disagree entirely.  There's nothing wrong with setter injection if used correctly.  It can actually help with automation quite a bit if you have a factory or DI container that is spawning objects.  It can check if an object implements an "aware" interface, and if so give it what it needs.  Symfony is doing that in a few places, Drupal is doing it in a few places, PSR-3 has it...  Keep it in.

@Larry - that's exactly the part I fight every day, be it at work or just as a mere OSS supporter.

[Evert Pot]

>> I still think that Evert's original proposal is probably closer to what most member projects are already doing. A survey may prove me wrong, though.
>
> Or it may prove you more right than you know; if the proposal is shown to be close to what is already in use, then hooray!

Secretly I also still prefer my own proposal ^_^. I'd +1 the current proposal too though..

Evert

[Amy Stephen]

Membership needs to decide what to do here.

Robert Hafner - I do not believe that comment was intended to discount your involvement. I think Paul was being articulate, nothing more than that.

However, I do think that when things get as out of whack, as this effort is, then the ones who are responsible to fix it are the membership. Before anyone, especially those of us who do not have any rights or ability to vote, put more time into it, it would be appropriate for the membership to decide what they want done here.  This one is out of control, please bring it back into some form that it can be worked on without wasting anyone's time.

Paul Jones - just an FYI: the Joomla project *has* implemented this interface. (So have I, but I'm not a member, however I can be a pain in the ass and that should count as something!)

Cache is about as easy as it gets, people. Get, Set, Delete, Clear. Go about your business. This isn't complex stuff. We should be able to do this one.

We need to avoid getting hung up on perfection. Guiding projects to share software is where good things happen. These Interfaces are just ways to help get that ball rolling. It's not sacred writings that will carry meaning for centuries.

More ranting...pleading...cheering, etc.

[Noah Goodrich]

I manage GacelaPHP which as a stand-alone Data Mapper framework would benefit largely from being able to hot-swap caching libraries with a standardized interface.

One question I have looking the proposal is why increment() has been omitted when a number of caching engines provide native support for incrementing a value?

If increment() isn't part of the standard, what should be the de facto way of mimicking increment functionality when consuming a library that implements this standard?

[Robert Hafner]

>> • eZ Publish - couldn't find the source

eZ Publish switched over to using Stash. In other words, they've already implemented the competing standard. Just check their composer file to see for yourself-

https://github.com/ezsystems/ezpublish-kernel/blob/master/composer.json


Robert

[Taylor Otwell]

Laravel's cache interface is very much similar to the current proposal, with the only exception being we return "null" on cache misses rather than having a CacheValue object of some sort.

On Wednesday, May 15, 2013 7:09:59 PM UTC-5, pmjones wrote:

On May 15, 2013, at 6:47 PM, Paul Dragoonis wrote:

> If nobody has any changes to make then I'm going to call up a vote on this within the next few weeks.

One addition: there needs to be a survey of the existing member cache systems that shows how they currently operate, similar to how a survey was done for PSR-1, PSR-2, and PSR-3.

If the proposed cache ends up being wildly different from those, then I'd suggest the proposal would need to be modified (but wait and see -- it might be close indeed).


-- pmj

[Jean-François Simon]

I think `increment()` should be part of the interface too.

If I build a library based on the cache and I use `PSR/Cache`, I will only rely on the interface for interoperability. If I have to increment/decrement interger value I will have to reimplment these methods with `get()` + `set()`. It's a performance issue (2 requests instead of 1). Caching is all about performance.

Of course, interface is the "minimal contract" of the backend which could implement these methods, but if I have to check if backend class supports or not incrementing, the interface does not fulfill its role.

Furthemore, calling `increment()` with a negative argument looks really weird to me, so I think `decrement()` should be part of the interface too.

Le jeudi 16 mai 2013 01:47:46 UTC+2, Paul Dragoonis a écrit :

Hey all,

The proposal is a result of the review of many existing PHP cache systems. 

To name a few: Stash, DoctrineCache, PHPRedis Extension, Memcached Extension, PPI\Cache.

The cache proposal hasn't changed in a few months now and I'm curious to know what's missing, I'd like people to actually contribute to the proposal with any changes they feel are necessary rather than just giving their two cents on the mailing list.

If nobody has any changes to make then I'm going to call up a vote on this within the next few weeks.

[FGM at GMail]

The same reasoning applies to CAS operations  which I suggested months ago, and which was rejected because some cache types (e.g. files) only support get and set.

--

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/42961bab-fd81-4d7f-a1ca-ccfc58f3ab0f%40googlegroups.com?hl=en.

[Jean-François Simon]

You're right, `checkAndSet()` method should also be part of the interface.

Indeed, files only support `get()` and `set()` method natively (the same goes for database), but `increment()`, `decrement()` and `checkAndSet()` are so easy to implement that I don't see an argument here!

[Hossein Zolfi]

Some cache engine does have increment method (APC as example), Some people on github suggest it, but I propose to some interface for doing that (In hope
this place is where that I can propose it)

I think we can have some other interfaces for making increment happen, some thing like following

inteface IncrementableItemInteface 
{
    public function increment($value = 1);
}

And then, for some cache engine, we can have CacheItem class that implements IncrementableItemInteface, we can check just by instance-of

   public function workOnSomeItem(CacheItem $cacheItem)
   {
       if ($cacheItem instanceof IncrementableItemInteface) {
             $cacheItem->increment(123);
       }
    }

So I propose to have some interfaces  for having some methods (increment as example)
I have commented on github (https://github.com/php-fig/fig-standards/pull/96#issuecomment-18115823) and Simon told me
that I must do it here.

Best regards

[Noah Goodrich]

I maintain a stand-alone Data Mapper that utilizes the increment() functionality in memcache. I'm looking at the standard from the viewpoint of a library that will consume PSR\Cache implementations as drop-in replacements without requiring customization.

This standard doesn't do much good if everyone who uses my Data Mapper library has to customize their chosen Cache library. As such and considering incremeting/decrementing in your cache to invalidate old caches when updates happen is a VERY common practice, I think the PSR needs to deal with the issue in some way.

Now that said, considering that some caching engines support increment functionality, I would suggest that 

1) CacheItem::increment() should be a required part of the interface.

2) For those engines that do not provide this support natively, CacheItem should also have an update() or set() method to allow for updating the value of the currently retrieved CacheItem which can be used to manually increment the CacheItem value in the increment() method

Otherwise, in Gacela for example, when incrementing a cache key, I will have to do something like this:

if(method_exists($obj, 'increment')) {

    $obj->increment();

} else {

   $val = $obj->getValue();

   $cache->set($obj->getKey(), ++$val);

}

Do you really all see that as preferable to force the libraries consuming the your Cache interface to manually check and see whether or not increment is available? Or perhaps you're suggesting that every Cache implementation should force consumers to manually get() and set() the value when incrementing? Frankly both suggestions sound like adding pain to the developers consuming these interfaces rather than simplifying our workflow.

[Jean-François Simon]

In the first place I need to precise that `increment()` method can't stand in the `CacheItemInterface` because items are not meant to be aware of the cache backend. This would rather be `CacheInterface::increment($key, $value)`.

Increment, decrement and CAS (which does not mean `checkAndSet` as I said previously, but `compareAndSwap`) are primitive operations, commonly used in a cache system. Why not adding them to the `CacheInterface`? Is it so awefull? Does someone have a convincing argument against adding these methods? I'd like to understand!

[Florin Patan]

Hello there,

I'll address all of the above comments regarding the increment/decrement and CAS in it's many forms.

First of all, caching is a two stage issue that will be addressed in this way: a simple interface, current PSR, and a 'advanced'/richer interface(s) in a later PSR.

- increment and/or decrement are usually encountered in APC/Memcached/Redis but I'm not sure how this relates to caching. Can you please provide me an example of a practical situation where this is encountered? I'm talking strictly about caching not a interface/abstraction layer to the above engines, just caching. I'm sorry but I can't come up with my own right now and this will help adding them in the initial proposal and not in the second one.

- CAS is not something that every storage engine supports it and emulating it wouldn't be a good idea imho. While it's true that APC/Memcached have it, Redis only provides an emulation for this and from my research it won't support a real CAS operation any time soon. What about other storage engines? Maybe this can be done in the second PSR related to caching?

Since Paul is now in charge of this PSR what I've wrote above maybe invalidated by him but this is my opinion.

Best regards,

Florin

[Florin Patan]

Robert, it seems that you still don't want to help out the community and express your view point on some questions that were addressed here a couple of months ago and you said you'll respond 'by the end of the week'.

And I'm not sure about this either: 'they've already implemented the competing standard'. They've just used a library, Stash, instead of another library, Doctrine Cache. Is Doctrine Cache another competing standard?

To me it seems that you think as your library being the only one on the Internet and you being the only one who knows something about caching. If so, please enlighten us as well, we are still waiting for your answer, you know?. Or you are still missing the point that we want to have something that's simple, fast, extensible and that gets the good points from everything out there?

And no, I'm not the person who's politically correct, I'm the one who tells people what it sees without reservations so don't feel offended, it's nothing personal :)

Patiently (still) waiting for the answers on some questions from a couple of months ago (and some from back in November 2012),

Florin

[Noah Goodrich]

Florin,

You can see how Gacela's Mapper class utilizes increment in specifying the current version of the cache:

https://github.com/energylab/gacela/blob/master/library/Gacela/Mapper/Mapper.php

Look at the _cache() and save() methods to see how the version is determined and updated.

I actually blogged on this topic some time ago: http://noahgoodrich.com/caching-data-sets/ as have others. For example: http://www.regexprn.com/2011/06/web-application-caching-strategies_05.html

When I was initially researching the problem for Gacela I found numerous examples all implementing this paradigm. I'm surprised you've not seen it before.

[Jason Judge]

On Friday, 17 May 2013 23:47:22 UTC+1, Robert Hafner wrote:

>>         • eZ Publish - couldn't find the source


eZ Publish switched over to using Stash. In other words, they've already implemented the competing standard. Just check their composer file to see for yourself-

https://github.com/ezsystems/ezpublish-kernel/blob/master/composer.json

It's a competition?

[Taylor Otwell]

I would suggest a PSR IncrementableCache interface in that case, in keeping with the Interface Segregation Principle.

[Robert Hafner]

Frankly I'm frustrated with this entire group and the entire process. We keep revisiting the same issues every couple of weeks as if they're new, and every time progress is actually made on something it disappears a few weeks or months later when new people come in with brand new proposals and make no attempt to actually work with the existing ones. The voting members won't get together to say what's important to them, so we end up debating minor issues back and forth without knowing what people actually want.

The longer I'm involved with this group the more disgusted I am. I spent months working to try to get a standard in play, only to have you guys bastardize it *without even attempting to work with me*, been pushed out of conversations because I'm not a voting member, and when I do try to contribute I get crap like "you think as your library being the only one on the Internet and you being the only one who knows something about caching"- or people just take the conversation to IRC so they don't have to deal with openness or transparency. On the one hand it's very difficult to work with people who would rather start fresh every two months so they could put their name on the top of the standard, ignoring the work others have done, but on the other hand it's hard not to get involved when the standards they're pushing will have huge long term effects.

You're right, I did promise to get a response back to you guys and I did fail on that front. It's been 17 months since I first put my proposal out, I guess I'm just frustrated that you guys decided to steal half of it as your own (in your own repository, no forks or anything so people can see the work I did) and shove through a bastardized version in a few month rather than work on something that has had almost a year and a half worth of work beyond it. It's also insanely frustrating to spend so much time trying to get people to come together around something, only to have it thrown out so we can rush through a half baked proposal. I also had some personal stuff come up which prevented me from responding (my mom had a brain tumor scare, fortunately it turned out to be something else but to say I had other priorities than caching would be an understatement).

I am getting more involved now, because I'm not just going to give up and let you guys push through something damaging. My main method has been to make my library fit the standard that everyone in this group spent the last 17 months working on, and then try to get the frameworks to adopt that. I think rather than voting a standard through here you should try implementing it first, so there's actually a library that matches it, and then we should let the best standard win by seeing which is actually more usable in the real world.

Robert

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/a48c2de9-4d53-496b-83b8-ae66ccebc82e%40googlegroups.com?hl=en.

[Robert Hafner]

It's not a competition, but when people are excluding information specifically to make a point it's a bit underhanded and the correct information should be pointed out. If the goal of that email was for people to know what the voting members are using for caching, then skipping over the ones that don't fit your viewpoint seems problematic at best.

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/7abd31d3-7f42-4592-8c3c-022f356f5e42%40googlegroups.com?hl=en.

[Florin Patan]

Robert, Amy excluded eZ Publish because she wrote this:

"So, I took a quick first stab at simply identifying libraries. Maybe if we can confirm this is the scope of cache libraries? Then, if there are so few participating, maybe Paul can focus on their feedback, involvement? 

[...]

- eZ Publish - couldn't find the source"

Then she was 'corrected' by pmj with this: "

 • eZ Publish - couldn't find the source 

Source appears to be at <http://svn.ez.no/svn/ezcomponents/trunk/Cache> 

"

As you can see, two people made the same mistake, not noticing the change but I'd think you shouldn't be that angry about it. And even if you might try to argue that Amy participated in the later discussions about caching, I don't think you can rule that pmj is biased, no?

Thanks for sending the notice thought :)

[Florin Patan]

Hi Robert,

- For everyone else, I'll stop replying out of scope of this thread, please excuse me this one last time, please skip it if you got something better to do with your time. Thanks -

I was frustrated as well, I understand you, but I've expressed this in another thread, Fabien and the rest of the community got the message and with the idea that Fabien had it seems that things will get better so frustration is over and since I've got time to get involved again into community, I'm doing so. So it seems that even if I'm not a voting member, nor do I think I should be one, things can be changed/done as non-voting member if you can deliver a message and there's enough interest for it. If not, life goes on :)

If you don't like the group, step out and never go back, no one is holding you hostage. But don't step out, then come back with some: no one is looking at my work, you've got it all wrong, it's not good and then go back out. Now that you are back, can you reply to it or you are still interested in replies like this?

"The longer I'm involved with this group the more disgusted I am. I spent months working to try to get a standard in play, only to have you guys bastardize it *without even attempting to work with me*, been pushed out of conversations because I'm not a voting member, and when I do try to contribute I get crap like "you think as your library being the only one on the Internet and you being the only one who knows something about caching"- or people just take the conversation to IRC so they don't have to deal with openness or transparency. On the one hand it's very difficult to work with people who would rather start fresh every two months so they could put their name on the top of the standard, ignoring the work others have done, but on the other hand it's hard not to get involved when the standards they're pushing will have huge long term effects."

I'm really not convinced by this seeing: https://github.com/php-fig/fig-standards/pull/11 and then https://github.com/php-fig/fig-standards/pull/17 all I can see is that Evert opened a proposal a couple of months before you, he's the first one to tackle the cache subject then you opened a second one. May I ask you, where is your spirit of cooperation then?

Now, for a bit of a history lesson: 

When I've opened my proposal was because I was trying to get caching into Symfony2 core, as I needed it on a very large website I was working for and I thought that since I'm doing it and it's a sensible subject, why not have it in the core. I've worked with @stof, thank God for his patience, and then @lsmith I think suggested to head over to FIG and either embrace a discussion of make a new proposal. Nobody was talking about caching anymore for like 4-5 months or so, I've created another one and that's it. Since I'm actually a pretty decent developer, I was able to read the proposal from Evert, Doctrine/Cahe, Zend/Cache and Stash and then I've decided I like Everts' and Doctrine/Cache way of doing things better, I've found Stash to be unnecessarily complex, so I've took what it seemed to me as being good and came up with the proposal. I've named people in the thread as source of inspiration and that's it. This is who we've got 3 proposals, where I've named mine a bit more ironically in order to gauge some interest for the subject, not it in particular.

Next someone told me: hey, now they are 3 proposals, if you want PSR/Cache why don't you try and unify them or talk to the authors of the other two to see if you can drop yours and get behind of the existing ones. And so I've did, I've talked to Evert on IRC and then tried to talk to you and be rejected in a very rude manner (guess who still has the archive ;) ). I've even sent you an e-mail when I was working for Symfonys' component but I still haven't had a reply to it.

Fortunately Paul took over and unified them and now we got this so please, give your technical input on this matter and nothing more.

All this time (since you've opened your proposal), when ever you felt like replying to something that wasn't what you were expecting, you've just lashed out at people who tried to do things differently that you and you ignored people who wanted to collaborate with you. The fact that you are saying: "I am getting more involved now, because I'm not just going to give up and let you guys push through something damaging. My main method has been to make my library fit the standard that everyone in this group spent the last 17 months working on, and then try to get the frameworks to adopt that." only makes me sad because you've still chose to actually express any technical argument as to why this is so freaking and damaging but you instead found time to write an rather poor reply.

If you want to promote your library that's fine, do so, but don't do it with force and not in this way, that's a conspiracy against you or something and that people can't see the genius behind your work, ok?

I'm not a voting member nor have I ever said that my proposal, or any proposal, is better or worst, I've simply asked for input from everyone that was wiling to give it and I've tried to come up with arguments when things weren't clear or to change when things needed to be changed or given my input when I felt I had something to say, that's it. Please be a man and do so as well since I sincerely couldn't care less about who's right and who's wrong as long as something good comes out of this.

Right now, for me you are a man who broke his word (hint: I'll reply by the end of the week thingy that you've said on your own then vanished) and I'm a man who can't write caching interfaces because I'm bastardizing your work. Since 99% of my work under NDAs and I was forced to keep my OSS contributions low/rare because of them (not the case anymore at my current company) and because I don't want to reinvent the wheel by doing another Doctrine/Cache, Zend/Cache or whatever/Cache does it mean I can't think for myself and create something on my own?

Florin

[Amy Stephen]

Robert -

I make this suggestion respectfully, if I were you, I would wait and return when you can accept the situation, as it is, warts and all, and feel good about your time involvement. Life is simply too short to participate with activities that make you that frustrated. If your situation is anything like mine, there's too much to do and not enough time to do it. The other thing to remember is if it's that frustrating for you it can rub off on others, too, and overall productivity could get worse.

I don't share your concern about any potential damage. There are many developers with cache packages who can help build a decent first pass. We can always improve it, it won't be the end of the world.

Maybe give it some time. That'd be my recommendation.

So glad to hear your mother's situation turned out to not be as serious. My father has had brain surgery and it is a tough road back. Reminder to all of us - enjoy your life - put your time into what you love.

Cheers.

[Amy Stephen]

My apologies for missing eZ Publish in the list. I missed a few of them. I was pretty busy that day but I wanted to see what I could find quickly. If I couldn't find the library in the first 5 minutes, or so, I moved on. For the most part, I think (?) those that I did not find weren't on github. I don't know, it wasn't my best effort. =)

[Paul Dragoonis]

I'm doing this survey but the ZF2 code is an absolute minefield.

How does one simply, set,get,delete,clear - data from a given cache backend such as APC,Memcached..etc

On Thu, May 16, 2013 at 8:03 PM, Amy Stephen <amyst...@gmail.com> wrote:

Oh sure, be charming, Paul. Like that is playing fair!

Now, here's the difference. First, I think a survey is good if for no other reason than than to begin building support for the PSR and start building involvement. But, it has little use at the end of the project, although it's tough to argue with the notion that FIG should vote something of little value or quality in on the basis that someone worked hard. I agree on that.

In your case, a survey was helpful because you were being inundated with the tabs versus spaces crowd and I hoped it might save you.

I'm a little worried about creating an impression that member projects do not have to pay attention, that mechanisms are in place to make certain solutions will easily work for them. And, frankly, I would expect you to push back on such a notion, too.

So, I took a quick first stab at simply identifying libraries. Maybe if we can confirm this is the scope of cache libraries? Then, if there are so few participating, maybe Paul can focus on their feedback, involvement?

Or, other ideas. Going out for a while, will check back later to see if I can help.


Member projects without cache class:

1. Amazon Web Services SDK
2. Apache log4php
3. Assetic
4. Buzz
5. Aura Project - no?

1. eZ Publish - couldn't find the source

1. Jackalope
2. Packagist
3. PEAR, PEAR2
4. phpBB
5. phpDocumentor
6. PPI, PPI2 - probably waiting for standard ? https://github.com/ppi/cache-module
7. Propel, Propel 2
8. SabreDAV
9. SugarCRM - ???

1. Symfony, Symfony2 - don't have one

1. TYPO3 - couldn't find it

1. Zikula looks like they might be using Doctrine's cache?

These are links to member cache that I was able to quickly find:

1. Agavi http://trac.agavi.org/browser/trunk/src/config/AgaviConfigCache.class.php
2. CakePHP, CakePHP 2 http://book.cakephp.org/2.0/en/core-libraries/caching.html
3. Doctrine, Doctrine2, et al. http://docs.doctrine-project.org/en/2.0.x/reference/caching.html
4. Drupal http://api.drupal.org/api/drupal/includes!cache.inc/interface/DrupalCacheInterface/7
5. Joomla - https://github.com/joomla/joomla-framework-cache (implemented)
6. Laravel - https://github.com/illuminate/cache/blob/master/StoreInterface.php
7. Lithium https://github.com/UnionOfRAD/lithium/blob/master/storage/Cache.php
8. Packagist n/a
9. PyroCMS https://github.com/pyrocms/pyrocms/blob/b0cc973f7abe2285e559105cea6a69a3579ed101/system/codeigniter/libraries/Cache/Cache.php
10. Zend Framework 2 https://github.com/zendframework/Component_ZendCache

--
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/a4653852-4d3a-464d-8614-cafd1a713cb9%40googlegroups.com?hl=en.

[Paul Dragoonis]

Here's the survey so far peeps, if it's incorrect or i've missed out any member projects that do have a cache component of their own please let me know.

https://docs.google.com/spreadsheet/ccc?key=0Ak2JdGialLildEM2UjlOdnA4ekg3R1Bfeng5eGlZc1E&usp=sharing

[Florin Patan]

I think you should look here: https://github.com/zendframework/zf2/blob/master/library/Zend/Cache/Storage/StorageInterface.php

Also, I do think that including a increment method to the interface would make sense after reading the articles mentioned somewhere here, what do you think?

Regards,

Florin

[Paul Dragoonis]

Yeah, I'll add them, an the multiple methods too.

As for the actual proposal's classes I've made a new CacheMultipleInterface and want to create a CacheIncrementableInterface, i'd like to find a shorter name for the latter class name to explain "increment" and "decrement" methods.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/27c39b65-43de-4ed5-8261-8315c8e63658%40googlegroups.com?hl=en.

[Paul Dragoonis]

I have updated the survey to include all increment and decrement methods.

https://docs.google.com/spreadsheet/ccc?key=0Ak2JdGialLildEM2UjlOdnA4ekg3R1Bfeng5eGlZc1E#gid=0

[Ryan McCue]

Paul Dragoonis wrote:
> Here's the survey so far peeps, if it's incorrect or i've missed out any
> member projects that do have a cache component of their own please let
> me know.
>
> https://docs.google.com/spreadsheet/ccc?key=0Ak2JdGialLildEM2UjlOdnA4ekg3R1Bfeng5eGlZc1E&usp=sharing

FWIW, the SimplePie cache interface has similar methods, but the cache
is one-object-per-cached-object, rather than per-bucket:

https://github.com/simplepie/simplepie/blob/master/library/SimplePie/Cache/Base.php

The relevant methods, with what they map to in the proposed interface:
load (get), save (set), mtime (?), touch (?), unlink (remove)

For these methods that don't map to an existing method, what would
replace them? As far as I can tell, there's no concept of metadata in
the interface, whereas most adapters do contain this (as you can see
with the TTL parameter).

My guess is that the interface is meant to handle all of this behind the
scenes and not expose it, but for more complicated end uses, this is
required.

Thoughts?

--
Ryan McCue
<http://ryanmccue.info/>

[Paul Dragoonis]

Hi Ryan,

I can't see from that link you posted where you obtain data or delete it. I only see save().

--
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/519F8ED3.1080806%40rotorised.com?hl=en.

[Ryan McCue]

Paul Dragoonis wrote:
> Hi Ryan,
>
> I can't see from that link you posted where you obtain data or delete
> it. I only see save().

The data is loaded in __construct() and unlink() is used to delete the data.

e.g.
https://github.com/simplepie/simplepie/blob/master/library/SimplePie/Cache/Memcache.php

[Paul Dragoonis]

Hi Ryan,

I've added SimplePie to the list, can you confirm that it's correct?

--
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/519F918C.8030903%40rotorised.com?hl=en.

[André R.]

On Saturday, May 18, 2013 12:47:22 AM UTC+2, Robert Hafner wrote:

>>         • eZ Publish - couldn't find the source


eZ Publish switched over to using Stash. In other words, they've already implemented the competing standard. Just check their composer file to see for yourself-

https://github.com/ezsystems/ezpublish-kernel/blob/master/composer.json

Correct, we didn't find any other options for the time being, so that is what we are using now as opposed to building our own which is what pmjones was hinting we where still doing above.

But for the record, our documentation is very clear on the fact that this might change in the future, so any custom code relying on the StashBundle cache service can, and probably will, break in our future releases.

 

Robert




On May 16, 2013, at 1:18 PM, Paul Jones <pmjo...@gmail.com> wrote:

>
> On May 16, 2013, at 2:03 PM, Amy Stephen wrote:
>

>> I think a survey is good if for no other reason than than to begin building support for the PSR and start building involvement. But, it has little use at the end of the project,
>

> I would argue that the survey is *best* at the beginning of the project, because it will help lead efforts in the direction of "codifying commonalities between member projects."  If the survey comes at the end, then it is still useful, because it tells us how much of the proposal is brand new stuff that doesn't exist yet in a member implementation anywhere.  (Per Larry Garfield's survey, the leading goal of the group is to codify what exists, and only secondarily to make new things that don't exist yet, which still makes the survey useful.)
>
>

>> I'm a little worried about creating an impression that member projects do not have to pay attention, that mechanisms are in place to make certain solutions will easily work for them.
>

> On the contrary, I think member project representatives will pay *more* attention when they see their project names in discussions that compare and contrast their approaches.  Indeed, I think it will drive their participation; everyone wants to make sure their way of doing things is fairly represented.
>
>

>> So, I took a quick first stab at simply identifying libraries. Maybe if we can confirm this is the scope of cache libraries? Then, if there are so few participating, maybe Paul can focus on their feedback, involvement?
>>
>> Or, other ideas. Going out for a while, will check back later to see if I can help.
>>
>> Member projects without cache class:
>

> (FWIW, I googled the project name and "cache" for the following; the best way to determine, though, is to grab the codebase for each project and grep for "cache").
>
>>         • Aura Project - no?
>
> Aura does not, but Solar does: <http://solarphp.com/apidoc/package.Solar_Cache>
>
>

>>         • eZ Publish - couldn't find the source

>
> Source appears to be at <http://svn.ez.no/svn/ezcomponents/trunk/Cache>
>
>

>>         • PEAR, PEAR2
>
> PEAR definitely has a caching package; two, in fact:
>
> - http://pear.php.net/package/Cache
> - http://pear.php.net/package/Cache_Lite
>
>
>>         • phpBB
>
> I *think* this is the phpBB cache system, but it might be an add-on: <https://wiki.phpbb.com/Cache>
>
>>         • Propel, Propel 2
>
> Propel 1 at least has some sort of caching system: <http://propelorm.org/behaviors/query-cache.html>
>
>
>>         • SugarCRM - ???
>
> This document indicates they have one: <http://developers.sugarcrm.com/wordpress/2011/08/30/deciphering-the-sugarcrm-cache-directory/>
>
>
>>         • Symfony, Symfony2 - don't have one
>
> Symfony 1 had caching, indicated by this document: <http://symfony.com/legacy/doc/book/1_0/en/12-Caching>
>
>
>>         • TYPO3 - couldn't find it
>
> Seems to have one: <http://wiki.typo3.org/Caching_framework>
>
>

>> These are links to member cache that I was able to quickly find:
>>         • Agavi http://trac.agavi.org/browser/trunk/src/config/AgaviConfigCache.class.php
>>         • CakePHP, CakePHP 2 http://book.cakephp.org/2.0/en/core-libraries/caching.html
>>         • Doctrine, Doctrine2, et al. http://docs.doctrine-project.org/en/2.0.x/reference/caching.html
>>         • Drupal http://api.drupal.org/api/drupal/includes!cache.inc/interface/DrupalCacheInterface/7
>>         • Joomla - https://github.com/joomla/joomla-framework-cache (implemented)
>>         • Laravel - https://github.com/illuminate/cache/blob/master/StoreInterface.php
>>         • Lithium https://github.com/UnionOfRAD/lithium/blob/master/storage/Cache.php
>>         • Packagist n/a
>>         • PyroCMS https://github.com/pyrocms/pyrocms/blob/b0cc973f7abe2285e559105cea6a69a3579ed101/system/codeigniter/libraries/Cache/Cache.php
>>         • Zend Framework 2 https://github.com/zendframework/Component_ZendCache
>

> /me nods
>
> It appears that a significant number (a majority?) of the voting member projects have a cache implementation of some type.  Reviewing those implementations, determining their commonalities, and identifying their weak points (if any) should be the first order for any caching proposal.
>
>
> -- pmj
>

> --
> 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.

[Paul Dragoonis]

I've now updated the survey to show the results of the survey and the popularity of what methods are being used

https://docs.google.com/spreadsheet/ccc?key=0Ak2JdGialLildEM2UjlOdnA4ekg3R1Bfeng5eGlZc1E#gid=0

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/41f19463-e6e1-40ee-96d2-fe3bccea2475%40googlegroups.com?hl=en.

[Phil Sturgeon]

Actually PyroCMS is:

set / get / forget / clear / NA / NA

We use a Composer package for this in new versions, the Cache library you evaluated was the CodeIgniter library and is deprecated.

[Paul Dragoonis]

Thanks for letting us know that.

I've updated the method names and the counts on the results list below.

--

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/995781c7-6e11-4053-b784-d435ab3526a0%40googlegroups.com?hl=en.

[Paul Jones]

On May 24, 2013, at 10:07 AM, Paul Dragoonis wrote:

> Here's the survey so far peeps, if it's incorrect or i've missed out any member projects that do have a cache component of their own please let me know.
>
> https://docs.google.com/spreadsheet/ccc?key=0Ak2JdGialLildEM2UjlOdnA4ekg3R1Bfeng5eGlZc1E&usp=sharing

Nice! I know it's tedious but I do think it's informative and useful. Some notes:

- Do we want to include native or extension caches like APC, memcache, memcached, etc?

- I see a "writing method" noted, but at least some have a "write only if not already in the cache" and "write over what's in the cache". Cf. the differences between <http://php.net/manual/en/function.apc-store.php> and <http://us3.php.net/manual/en/function.apc-add.php>. Does that need to be noted here?

- Another nice addition might be "the return results from reading the cache on a hit and a miss".

Looking like a real good start here.


-- pmj

[FGM at GMail]

I think including the respective capabilities of the frequent underlying implementations (APC, Memcached, flat files, databases, ...) might make al sense: inc/dec, which you already added, multiple operations,  check-and-set...

2013/5/24 Paul Jones <pmjo...@gmail.com>

--
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/A08C38A0-D46C-49E9-9C2D-5AB1BD3EB284%40gmail.com?hl=en.

[Paul Dragoonis]

Hey FGM,

I've updated the survey to include inc/dev and multiple operations.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANqRZ1PFTLDTYFNG9L%2Bsi-wnUE-r6OnT416sas5Lqj7KQTSUoQ%40mail.gmail.com?hl=en.

[Christoph Mewes]

Hi everyone,

I just wanted to share my experiences from working on our caching library BabelCache[1], which currently gets a major overhaul.

For now, I've added an experimental support[2] for the proposed interface and can from my end confirm that most of the proposed operations are well portable (supported by many caching backends). Filesystem proves to be slowest one, but as long as there are PHP-only fallbacks for high-level operations like inc/dec, I would be fine to add more. Currently, I settled with

* AdapterInterface: get, set, remove, exists, clear

* IncrementInterface: increment (there is no decrement here - yet?)

* MultiOpsInterface: getMultiple, setMultiple

* LockingInterface: lock, unlock

Whereas the AdapterInterface would pretty much map to the proposed CacheInterface (but Cache and Adapter are different terms in BabelCache, so don't get confused ;-)

The only thing that worries me is the TTL support in the proposal. By far not every backend supports a TTL and if supporting an expiration would be a requirement for implement the PSR interface, that could very well create some serializing overhead. One would have to encode the expiry into the cache item's value, which could in some storages kill the ability to increment easily (I think of Redis, which does support storing strings, so I have to serialize objects; but to use the INCR command, values need to be unserialized in Redis).

I'm very fine with offering it as it's currently: An optional feature the underlying backend does not need to support.

Sorry if this got mixed up somewhere in the discussion, I'm still unable to properly handle Google Groups.

Greetings,

    Christoph

[1] https://bitbucket.org/webvariants/babelcache/src/next/

[2] https://bitbucket.org/webvariants/babelcache/src/next/src/wv/BabelCache/Psr/Cache.php

[guilher...@gmail.com]

My personal guess is always reuse what was already discussed and is on market. Presenting.... JSR-107! =)

Specification: http://download.oracle.com/otn-pub/jcp/jcache-2_7-edr-spec/JSR107Specification.odt.pdf
API: https://jsr107.ci.cloudbees.com/job/jsr107api/ws/target/apidocs/index.html

If we want to start small... Cache interface is my best guess:

https://jsr107.ci.cloudbees.com/job/jsr107api/ws/target/apidocs/javax/cache/Cache.html

Cheers,

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAKxcST_rpdXz03A4Th9bpYLUf3CG%2BMSyzEEuuyHXD7DPxryCag%40mail.gmail.com?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Guilherme Blanco
MSN: guilher...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

[Paul Dragoonis]

Hi Christoph,

Thanks for introducing us to your caching lib and showing us your PSR compliant adapter it looks pretty clean.

One thing we are currently thinking about is how to name an interface to handle Increment / Decrement methods.

I've thought of CacheIncrementableInterface, what about CacheIncDecInterface? it's shorter and does what it says on the tin.

Anyone got some opinions on this interface name?

The locking is pretty trivial CacheLockingInterface

--

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/4db3e331-7c66-4697-bbb0-dd79391b1e3f%40googlegroups.com?hl=en.

[Christoph]

2013/5/25 Paul Dragoonis <drag...@gmail.com>

Hi Christoph,

Thanks for introducing us to your caching lib and showing us your PSR compliant adapter it looks pretty clean.

One thing we are currently thinking about is how to name an interface to handle Increment / Decrement methods.

I've thought of CacheIncrementableInterface, what about CacheIncDecInterface? it's shorter and does what it says on the tin.

I suspect most systems that offer an increment operation will also offer a decrement operation (or at least in that case it should be easy to implement in PHP with get+set). So I see no reason to have "Decrement" as part of the interface name (the same way it's not CacheLockingUnlockingInterface).

I also find the "Cache" prefix reundant. The interface is already in a "Psr\Cache" namespace, so "LockingInterface" is enough IMHO. But I'm relatively new to cleanly namespacing my classes, so maybe it's good to have the "Cache" part be in the interface name.

Everything else regarding the name is IMHO just wasted time. Pick one, settle on it and then have people complain about it forever. Just the way the world works. ;-)

Having multiple interfaces for extra functionality makes sense, IMHO. However, it makes my library somewhat harder, as I cannot have one single "PSR wrapper". Well, I could, but that would hide the specifics of the underlying adapter from the user.

But those considerations should not stop the PSR interface from being well structured.

Greetings,

   Christoph

[Paul Dragoonis]

On Sat, May 25, 2013 at 10:57 PM, Christoph <chri...@ymail.com> wrote:

2013/5/25 Paul Dragoonis <drag...@gmail.com>

Hi Christoph,

Thanks for introducing us to your caching lib and showing us your PSR compliant adapter it looks pretty clean.

One thing we are currently thinking about is how to name an interface to handle Increment / Decrement methods.

I've thought of CacheIncrementableInterface, what about CacheIncDecInterface? it's shorter and does what it says on the tin.

I suspect most systems that offer an increment operation will also offer a decrement operation (or at least in that case it should be easy to implement in PHP with get+set). So I see no reason to have "Decrement" as part of the interface name (the same way it's not CacheLockingUnlockingInterface).

I also find the "Cache" prefix reundant. The interface is already in a "Psr\Cache" namespace, so "LockingInterface" is enough IMHO. But I'm relatively new to cleanly namespacing my classes, so maybe it's good to have the "Cache" part be in the interface name.

Everything else regarding the name is IMHO just wasted time. Pick one, settle on it and then have people complain about it forever. Just the way the world works. ;-)

Having multiple interfaces for extra functionality makes sense, IMHO. However, it makes my library somewhat harder, as I cannot have one single "PSR wrapper". Well, I could, but that would hide the specifics of the underlying adapter from the user.

But those considerations should not stop the PSR interface from being well structured.

I agree that the interface names don't need the double Cache prefix.

 

Greetings,

   Christoph

On Sat, May 25, 2013 at 9:32 PM, Christoph Mewes <christo...@gmail.com> wrote:

Hi everyone,

I just wanted to share my experiences from working on our caching library BabelCache[1], which currently gets a major overhaul.

For now, I've added an experimental support[2] for the proposed interface and can from my end confirm that most of the proposed operations are well portable (supported by many caching backends). Filesystem proves to be slowest one, but as long as there are PHP-only fallbacks for high-level operations like inc/dec, I would be fine to add more. Currently, I settled with

* AdapterInterface: get, set, remove, exists, clear

* IncrementInterface: increment (there is no decrement here - yet?)

* MultiOpsInterface: getMultiple, setMultiple

* LockingInterface: lock, unlock

Whereas the AdapterInterface would pretty much map to the proposed CacheInterface (but Cache and Adapter are different terms in BabelCache, so don't get confused ;-)

The only thing that worries me is the TTL support in the proposal. By far not every backend supports a TTL and if supporting an expiration would be a requirement for implement the PSR interface, that could very well create some serializing overhead. One would have to encode the expiry into the cache item's value, which could in some storages kill the ability to increment easily (I think of Redis, which does support storing strings, so I have to serialize objects; but to use the INCR command, values need to be unserialized in Redis).

I'm very fine with offering it as it's currently: An optional feature the underlying backend does not need to support.

Sorry if this got mixed up somewhere in the discussion, I'm still unable to properly handle Google Groups.

Greetings,

    Christoph

[1] https://bitbucket.org/webvariants/babelcache/src/next/

[2] https://bitbucket.org/webvariants/babelcache/src/next/src/wv/BabelCache/Psr/Cache.php

--
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/CACvMGnBCMLSubDOoO4rdoTZS_pss-Zr_h%2B9NZPZ5MQDfsu%2BK9g%40mail.gmail.com?hl=en.

[Paul Dragoonis]

On Sat, May 25, 2013 at 11:25 PM, Paul Dragoonis <drag...@gmail.com> wrote:

On Sat, May 25, 2013 at 10:57 PM, Christoph <chri...@ymail.com> wrote:

2013/5/25 Paul Dragoonis <drag...@gmail.com>

Hi Christoph,

Thanks for introducing us to your caching lib and showing us your PSR compliant adapter it looks pretty clean.

One thing we are currently thinking about is how to name an interface to handle Increment / Decrement methods.

I've thought of CacheIncrementableInterface, what about CacheIncDecInterface? it's shorter and does what it says on the tin.

I suspect most systems that offer an increment operation will also offer a decrement operation (or at least in that case it should be easy to implement in PHP with get+set). So I see no reason to have "Decrement" as part of the interface name (the same way it's not CacheLockingUnlockingInterface).

I also find the "Cache" prefix reundant. The interface is already in a "Psr\Cache" namespace, so "LockingInterface" is enough IMHO. But I'm relatively new to cleanly namespacing my classes, so maybe it's good to have the "Cache" part be in the interface name.

Everything else regarding the name is IMHO just wasted time. Pick one, settle on it and then have people complain about it forever. Just the way the world works. ;-)

Having multiple interfaces for extra functionality makes sense, IMHO. However, it makes my library somewhat harder, as I cannot have one single "PSR wrapper". Well, I could, but that would hide the specifics of the underlying adapter from the user.

But those considerations should not stop the PSR interface from being well structured.

I agree that the interface names don't need the double Cache prefix.

One problem with that though,

We have Psr\Cache\CacheInterface, if we removed the prefix it would just be Psr\Cache\Interface, which doesn't make sense.

[Florin Patan]

Hey,

Having inc/dec in standard interface should be pretty easy and since most common engines (apc/memcached/redis/db) support this kind of operation I don't think it would be a problem. We could always return false for failing/not supported operation, no?

Maybe we can have a look for CAS as well in the first interface seeing that apc/memcached/redis/db engines all support it, no?

As for locking/unlocking, besides DB and, I think, Redis, there's no other engine that supports this kind of operation. Maybe you could consider CAS operations as being able to emulate but emulation vs native support are two different topics. I'm strongly against having locking support in a PSR for cache as there's a risk in implementation in doing something like using other keys * creating new keys named '$key . "_lock" ' for example to emulate this feature * which in turn it will create a disaster for the end-user.

Sure, everything is fine when you have 10 visitors / s but not all people have that.

Same goes for more sensible things like tags or namespaces. Maybe we could review them in a later/next PSR to extend this one but imho when we talk about cache we should always focus on why we need cache in the first place and what we expect from it to be.

Regards,

Florin

[Florin Patan]

Hello,

I've been doing some thinking in the light of the PSR-0 refactoring that's going on in the other thread and I think I have a problem with the current way of doing things.

If we want to skip the problems that users will face when having two autoloaders then we need to be careful not giving them two cache interfaces as well, it won't look too good for this group if we do this imho.

So here's the idea:

- make the CacheItem a bit more consistent: have setters/getters for Key/Value/TTL

- make all operations on the interface work only with CacheItem objects or collections.

This way, all the current methods, set/get/remove/increment/decrement will be available if we go to a later PSR in which we decide to enhance the CacheItem and say add tags to it.

The reason for doing this is simple.

If we'll have PSR/Cache and PSR/CacheTagsAndNamespaces then a user that's using PSR/Cache could safely upgrade the library that he's using to a library that's PSR/CacheTagsAndNamespaces compatible as all the basic operations will be the same and the only thing that will change will be that the end user now gets a couple more methods that his code isn't aware in the first place, so no harm done.

But if we decide that PSR/CacheTagsAndNamespaces will need a new function to save the now taggable item then we'll either end up with having a bunch of save methods either we'll break the existing one. Either case, bad things for the end user.

If this is not clear enough, I'm not very good at explaining things, let me know and I'll try to create a example to demo the things that I'm worried about.

Best regards,

Florin

On Thursday, May 16, 2013 1:47:46 AM UTC+2, Paul Dragoonis wrote:

Hey all,

The proposal is a result of the review of many existing PHP cache systems. 

To name a few: Stash, DoctrineCache, PHPRedis Extension, Memcached Extension, PPI\Cache.

The cache proposal hasn't changed in a few months now and I'm curious to know what's missing, I'd like people to actually contribute to the proposal with any changes they feel are necessary rather than just giving their two cents on the mailing list.

If nobody has any changes to make then I'm going to call up a vote on this within the next few weeks.

Thanks all and lets be productive and pragmatic to bring closure to a proposal that's been open for a long time now.

https://github.com/dragoonis/fig-standards/blob/master/proposed/psr-cache.md

Regards,

Paul Dragoonis

[Christoph]

2013/5/26 Paul Dragoonis <drag...@gmail.com>

On Sat, May 25, 2013 at 11:25 PM, Paul Dragoonis <drag...@gmail.com> wrote:

On Sat, May 25, 2013 at 10:57 PM, Christoph <chri...@ymail.com> wrote:

2013/5/25 Paul Dragoonis <drag...@gmail.com>

Hi Christoph,

Thanks for introducing us to your caching lib and showing us your PSR compliant adapter it looks pretty clean.

One thing we are currently thinking about is how to name an interface to handle Increment / Decrement methods.

I've thought of CacheIncrementableInterface, what about CacheIncDecInterface? it's shorter and does what it says on the tin.

I suspect most systems that offer an increment operation will also offer a decrement operation (or at least in that case it should be easy to implement in PHP with get+set). So I see no reason to have "Decrement" as part of the interface name (the same way it's not CacheLockingUnlockingInterface).

I also find the "Cache" prefix reundant. The interface is already in a "Psr\Cache" namespace, so "LockingInterface" is enough IMHO. But I'm relatively new to cleanly namespacing my classes, so maybe it's good to have the "Cache" part be in the interface name.

Everything else regarding the name is IMHO just wasted time. Pick one, settle on it and then have people complain about it forever. Just the way the world works. ;-)

Having multiple interfaces for extra functionality makes sense, IMHO. However, it makes my library somewhat harder, as I cannot have one single "PSR wrapper". Well, I could, but that would hide the specifics of the underlying adapter from the user.

But those considerations should not stop the PSR interface from being well structured.

I agree that the interface names don't need the double Cache prefix.

One problem with that though,

We have Psr\Cache\CacheInterface, if we removed the prefix it would just be Psr\Cache\Interface, which doesn't make sense.

It's not only weird, it's impossible to have an interface called Interface. So I would stick with

- Psr\Cache\CacheInterface

- Psr\Cache\IncrementInterface

- Psr\Cache\LockingInterface

To not talk about the naming forever, this shall be my final comment regarding this topic ;-)

 

Greetings,

   Christoph

[Paul Dragoonis]

I'm down with that.

 

To not talk about the naming forever, this shall be my final comment regarding this topic ;-)

 

Greetings,

   Christoph

--

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/CACvMGnCX6d4kV_5bw%2Bb4%2BvrKBihMzB4NQsd6FMAX6Ry2mYCFGQ%40mail.gmail.com?hl=en.

[Christoph]

2013/5/26 Florin Patan <flori...@gmail.com>

Hey,

Having inc/dec in standard interface should be pretty easy and since most common engines (apc/memcached/redis/db) support this kind of operation I don't think it would be a problem. We could always return false for failing/not supported operation, no?

Just a heads up: My unit tests just failed due to differences in the increment support.

- Memcached (1.4) seems to not allow negative values to be incremented ("set foo -24" + "incr foo" = error). Also, it never decrements below zero ("set foo 0" + "decr foo" = foo == 0).

- Redis happily supports incrementing and decrementing anything numerical.

- Both cannot handle increments on float values.

It would be important to specify excatly what increment() should do to a value.

a) increment should work for every numerical value => no atomic increment on memcached anymore

b) increment should work only for uints => no atomic increment on Redis anymore

I'm not sure myself what the best solution to this might be.

Maybe we can have a look for CAS as well in the first interface seeing that apc/memcached/redis/db engines all support it, no?

As for locking/unlocking, besides DB and, I think, Redis, there's no other engine that supports this kind of operation. Maybe you could consider CAS operations as being able to emulate but emulation vs native support are two different topics. I'm strongly against having locking support in a PSR for cache as there's a risk in implementation in doing something like using other keys * creating new keys named '$key . "_lock" ' for example to emulate this feature * which in turn it will create a disaster for the end-user.

In my library, I emulated the behaviour "natively" if the underlying storage supports adding new keys (where an add would fail if the key already exists). I decided to go that way cause this is still better than being completely generic and doing an exist()+set() combo (the completely generic fallback is still available, though).

Then there's the question on what a lock should actually do? For now, I'm just able to lock and unlock keys, but this does not have any direct effect on the cache. Should the lock be actually respected by the cache?

CAS operations are IMHO much harder to fake (if you want them to be as atomic as possible), but more adapters actually implement it, so there is less need to have a generic, non-atomic fallback. I could live with CAS not being part of the interface, to be honest. I never found CAS terribly useful.

Same goes for more sensible things like tags or namespaces. Maybe we could review them in a later/next PSR to extend this one but imho when we talk about cache we should always focus on why we need cache in the first place and what we expect from it to be.

Namespacing becomes incredible complex and slow if you need to implement it on top of a key-value based storage. I would hence also suggest not bothering with namespaces in the PSR interface.

Greetings,

   Christoph

 

[Cristian Datculescu]

First of all CAS is the only control mechanism that allows you to deal with concurrency issues. End of story. It is very useful, not like you said.

Second: you cannot implement a non-atomic CAS. There are too many ways to fail in there and you will never have 100% reliability. IMO, if CAS is not provided by the server itself, it is not worth the effort to veen try thinking about it. Beside this, there is no unified interface for using CAS across various vendors. For example memcached returns a set of tokens which are used in updating as well and update fails if tokens don't match, while redis implementation involves watching the keys you want to update (insert) and aborting the "transaction" if one of the keys has been modified.

[Jordi Boggiano]

How about LockableInterface / IncrementableInterface? I guess its another habit/religious thing but it feels more correct to me that a cache object is incrementable rather than increment.

Also it goes in the same direction as the LoggerAwareInterface we have in psr3

sorry for top post, crappy mobile email client.

---

From: Paul Dragoonis
Sent: 27/05/2013 14:20
To: php...@googlegroups.com
Subject: Re: PSR Cache - Ready for Vote? What's Remaining?

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAKxcST-XyCgMuLR5e9UE%3DpHtqgS-Wd551o6-x24w--pG5H1jtA%40mail.gmail.com?hl=en.

[Ryan McCue]

Christoph wrote:
> It would be important to specify excatly what increment() should do to a
> value.
>
> a) increment should work for every numerical value => no atomic
> increment on memcached anymore
> b) increment should work only for uints => no atomic increment on Redis
> anymore

Option B can still be (mostly) atomic, it just needs to check before
hand that the value is not negative. All the increments will fail if the
value is negative, and all will succeed if it's positive. The only time
it may be dodgy is if the value is changed between the check and the
increment, however IMO that's an edge case that doesn't matter.

[Paul Dragoonis]

Am I correct in assuming this is an implementation-level decision on how users handle the parameters passed to increment()/decrement() methods ? 

On the topic of inc/dec, my gut feeling tells me that the following signatures should be enough

public function increment($key, $value = null);

public function decrement($key, $value = null);

The point of the optional values is that you can by default inc/dev by 1, similar to $i++ or $i--. However you can pass an inc/dev value such as int(25). This is how Memcached works. As for Redis they have 'inc' and 'incBy' which is the same functionality encompassed by the option $value parameter.

Does anyone have any concerns about the proposed method signatures above?

Thanks,

Paul

 

--
Ryan McCue
<http://ryanmccue.info/>

--
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/51A3799A.8080303%40rotorised.com?hl=en.

[Christoph]

2013/5/27 Paul Dragoonis <drag...@gmail.com>

On Mon, May 27, 2013 at 4:19 PM, Ryan McCue <li...@rotorised.com> wrote:

Christoph wrote:
> It would be important to specify excatly what increment() should do to a
> value.
>
> a) increment should work for every numerical value => no atomic
> increment on memcached anymore
> b) increment should work only for uints => no atomic increment on Redis
> anymore

Option B can still be (mostly) atomic, it just needs to check before
hand that the value is not negative. All the increments will fail if the
value is negative, and all will succeed if it's positive. The only time
it may be dodgy is if the value is changed between the check and the
increment, however IMO that's an edge case that doesn't matter.

Am I correct in assuming this is an implementation-level decision on how users handle the parameters passed to increment()/decrement() methods ?

For me it's more of a general discussion on how we want increment()/decrement() to behave. Just so we all know what to expect. For this, I'd like to specifiy the following as well:

- cache.remove("key).increment("key") = ?

- cache.set("key", 42).increment("key", -7) = ?

- cache.set("key", 23).decrement("key", 7) = ?

 

On the topic of inc/dec, my gut feeling tells me that the following signatures should be enough

public function increment($key, $value = null);

public function decrement($key, $value = null);

The point of the optional values is that you can by default inc/dev by 1, similar to $i++ or $i--. However you can pass an inc/dev value such as int(25). This is how Memcached works. As for Redis they have 'inc' and 'incBy' which is the same functionality encompassed by the option $value parameter.

It looks like all relevant storage backends support incrementing by an arbritary amount, so I'd be fine with adding the step value to the interface. But please let's have it

public function increment($key, $step = 1);

- $step is clearer than $value

- What would $value === null mean? Why add another, special default value, when there is already a perfectly sane one?

Regards,

   Christoph

[Paul Dragoonis]

We now have IncrementableInterface

https://github.com/dragoonis/fig-standards/blob/master/proposed/psr-cache.md#24-incrementableinterface

--

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/CACvMGnBES403fc2i9hq%3DZBdgFYrpe-E61mgmQ9nio%3DTUp%3DCB%3Dw%40mail.gmail.com?hl=en.

[Christoph]

2013/5/27 Paul Dragoonis <drag...@gmail.com>

We now have IncrementableInterface

https://github.com/dragoonis/fig-standards/blob/master/proposed/psr-cache.md#24-incrementableinterface

Looks good to me. :-) Where in the PSR would notes about the specific details on increment/decrement be put? I'd like to fork and extend the spec by stating what happens to unknown keys and stuff. Or is it easier if you put it in, Paul, so there is just one pull request to PSR and not a tree of them? I can live with either one :-)

Regards,

   Christoph

[Paul Dragoonis]

On Mon, May 27, 2013 at 7:37 PM, Christoph <chri...@ymail.com> wrote:

2013/5/27 Paul Dragoonis <drag...@gmail.com>

We now have IncrementableInterface

https://github.com/dragoonis/fig-standards/blob/master/proposed/psr-cache.md#24-incrementableinterface

Looks good to me. :-) Where in the PSR would notes about the specific details on increment/decrement be put?

The sections at the top of the proposal.

 

I'd like to fork and extend the spec by stating what happens to unknown keys and stuff. Or is it easier if you put it in, Paul, so there is just one pull request to PSR and not a tree of them? I can live with either one :-)

You normally fork my proposal and PR against it, but there's some kind of github forking limit issue so you can't fork it last time we checked so instead you gotta write out the text on a http://gist.github.com link for example and I paste it in.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CACvMGnCe8E_dhmM7vVzpv1c7Ryrqj%2BU4P%2BrDy08D0JT7fvdoXw%40mail.gmail.com?hl=en.

[Beau Simensen]

I'd like to fork and extend the spec by stating what happens to unknown keys and stuff. Or is it easier if you put it in, Paul, so there is just one pull request to PSR and not a tree of them? I can live with either one :-)

You normally fork my proposal and PR against it, but there's some kind of github forking limit issue so you can't fork it last time we checked so instead you gotta write out the text on a http://gist.github.com link for example and I paste it in.

I worked out a workaround to this problem specifically because fig-standards suffers from this GitHub limitation. Feel free to use a gist but there is no reason to avoid a PR if you are comfortable with a little URL hacking.

http://srcmvn.com/blog/2013/03/14/sending-a-pull-request-on-github-even-when-the-base-repository-you-want-is-missing/

[Christoph]

2013/5/27 Beau Simensen <sime...@gmail.com>

I'd like to fork and extend the spec by stating what happens to unknown keys and stuff. Or is it easier if you put it in, Paul, so there is just one pull request to PSR and not a tree of them? I can live with either one :-)

You normally fork my proposal and PR against it, but there's some kind of github forking limit issue so you can't fork it last time we checked so instead you gotta write out the text on a http://gist.github.com link for example and I paste it in.

I worked out a workaround to this problem specifically because fig-standards suffers from this GitHub limitation. Feel free to use a gist but there is no reason to avoid a PR if you are comfortable with a little URL hacking.

Hi again,

I went the easy road and put my thoughts into a Gist:

https://gist.github.com/xrstf/5659594

 

Regards,

   Christoph

[Donald Gilbert]

Anything remaining yet to bring this to a vote?

[guilher...@gmail.com]

Yes, I mentioned earlier that we should also take into consideration JSR-107, but none gave a single comment about it.

I'd argue that we should focus on looking into things that were already discussed to death by others and just reuse them.
We should start small and only consider the Cache interface, as detailed here:

https://jsr107.ci.cloudbees.com/job/jsr107api/ws/target/apidocs/javax/cache/Cache.html

For anyone interested, here are the links to Spec and detailed API:

Specification: http://download.oracle.com/otn-pub/jcp/jcache-2_7-edr-spec/JSR107Specification.odt.pdf
API: https://jsr107.ci.cloudbees.com/job/jsr107api/ws/target/apidocs/index.html

On Wed, May 29, 2013 at 5:31 PM, Donald Gilbert <dilber...@gmail.com> wrote:

Anything remaining yet to bring this to a vote?

--

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/0e1f36c7-f884-409b-a92c-7e9043de5fff%40googlegroups.com?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

[Amy Stephen]

Hey Guilherme -

I took a look at the links you shared last week. It was very interesting, in fact, I got lost on the various sites looking at class definitions, the methods and properties. I have also found looking at Java resources, like you shared, to be very helpful.

From my review, it seemed that JSR-107 was actually much more complex than what has been presented thus far in PHP-FIG.

For example, we have a remove($key) method.

JSR-107 has  remove (K key); remove(K key, V oldValue); removeAll(); removeAll(Set<? extends K> keys)

I found that increased complexity to exist for the gets, set, clear, etc. JSR-107 even has a set for replace which our approach would "bury" in the set method. Plus, there were three embedded interfaces, which wasn't clear to me what it meant but it did concern me that it could be tough to implement.

I apologize for not responding at that time. It is hard to guess what people think if they don't provide feedback.

I agree with you that a simple approach is preferred. IMO, what we have now should be easier to implement.

Again, thanks for sharing those resources. Love that stuff - have it all bookmarked.

[Moisa Teodor]

Hi all,

Regarding JSR107, I think it's pretty complex, as it also treats annotations and transactions. IMHO, the transactional part should be the subject of a different specification. Same with annotations.

There is also the cache functionality from Oracle Coherence, see http://docs.oracle.com/cd/E24290_01/coh.371/e22843/com/tangosol/net/cache/CacheStore.html which has:

 - load(Object key), 

 - store(Object, key, Object value), 

 - erase(Object key)

 - loadAll(Collection keys), 

 - storeAll(Map entries), 

 - eraseAll(Collection keys)

... which I think it's pretty simple, and resembles the current proposal. 

Regarding the current proposal, the only things I have to object against is the enforced enveloping of a cached value into a CacheItem (together with the whole CacheItem interface).

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAFp73XuOBo2edZnGi044j9BPqgmFQhpzV%3D2XOr00J1n_iyENAg%40mail.gmail.com?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Doru Moisa
web: http;//moisadoru.wordpress.com
tel: +40 720 861 922
Bucharest, Romania

[Florin Patan]

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAEJbJpi%2B2yDqHaW3dkGorUwEP%2BWDppdgOkBDpB0jdrkUKSjpSg%40mail.gmail.com?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
  

Hey,

> Regarding the current proposal, the only things I have to object against is the enforced enveloping of a cached value into a CacheItem (together with the whole CacheItem interface).

The reason to envelop the value in a object is that in this way you can store any value and then retrieve it from cache, be it null or false.

While the storage engines generally support storing any value, when you'll do something like:

$result = $cache->get($key);

you'd also need to see if the operation was a hit or a miss on the system and you can't do that with a straightforward comparison like

if ($result == false) or even if ($result === false)

as users might actually store that value inside the caching system. This way you can have:

if ($result->isMiss()) or if ($result->isHit())  (whichever is now in the proposal)

which are more verbose but are always there regardless of the operation result and the stored value.

I hope this makes things a bit more clear.

@Paul: This has been discussed a couple of times, maybe we should address/explain this better in the proposal?

----

Florin Patan

https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

  

[Moisa Teodor]

Hi Florin, all,

I followed the discussion around it, and I still keep my reserve around the enforcing of the CacheItem envelope. For the special cases you mentioned, you could always throw a CacheMiss exception, and treat it in a catch block, if needed.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAA9esyTm2vGSta%3D-7j5hy3Vi-1nCQGBDLswp%2BwPLXGBCMRA0fQ%40mail.gmail.com?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Paul Dragoonis]

If you can come up with some PROs for using CacheItem class instead of raw datatype values being returned then we could stick it next to the CacheItem section on the proposal.

 

----

Florin Patan

https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

  

--

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/CAA9esyTm2vGSta%3D-7j5hy3Vi-1nCQGBDLswp%2BwPLXGBCMRA0fQ%40mail.gmail.com?hl=en.