Make caching PSR-6 compatible

[magnusnordlander]

Hi,

I'm interested in making this SDK use a PSR-6 compatible cache instead of the built-in custom caching solution.

This would make it possible to better integrate the SDK with generic profiling tools like the Symfony Debug toolbar, Z-ray etc.

This would also make it possible to use the php-cache hierarchical cache or tagging cache to easily solve #48.

Would you be interested in merging such a PR if I make one?

[bretterer]

Hello @magnusnordlander
We do always welcome PR's. If you want to work on this for the SDK, we will be happy to look at it. The things we need to make sure of though is that it does not break backwards compatibility at all.
-Brian

[magnusnordlander]

Cool. I've begun working on this.

Now, when you say "does not break backwards compatibility at all", what do you mean? Without a defined API, pretty much anything breaks BC. Let me give you an example. Take Stormpath\Cache\Cacheable. That particular class consists only of protected and private methods, and is only known to be used by two other classes, Stormpath\DataStore\DefaultDataStore and Stormpath\Tests\Cache\CacheTestingMock.

Now, theoretically, someone else could be extending Stormpath\Cache\Cacheable in their application code, so that even if I update DefaultDataStore and CacheTestingMock accordingly, changes to Cacheable could break their application.

When you say no BC breaks, do you mean for classes/interfaces that the end user is meant to use (and if so, are those defined?), or do you mean for everything, as in the above example?

[bretterer]

Anything that an end user should be using. The best thing we have is what is in our documentation.

[magnusnordlander]

So, I've been working on this for a little more than a day now, and it pretty much works, and also fixes #48. This is my current diff: dev...ee1b96a

With regards to what I've talked about above concerning BC breaks, you'll see that much of the code has been pretty much updated to handle BC breaking changes there. I have some more ideas on how to handle the breaking changes currently in the changeset. Please let me know if there are any breaking changes in the changeset that does NOT need to be handled (I assume e.g. the removal of DefaultDataStore::getCacheManager since that one was marked as "will be removed in the future without warning").

Let me know if you have any feedback. I will be working on this again on Tuesday February 16th.

[bretterer]

Hi @magnusnordlander. I was just checking 8n here to see what the status I'd of this work.

Brian

[magnusnordlander]

Hi!

Everything has been merged and tagged upstream, so I'll be finishing up this branch today.

[bretterer]

@magnusnordlander Great! Thank you so much for your PR... I will get this in Review ASAP. PR #136