More complex handlers about stash HOT 6 CLOSED

"Driver" in this context is the equivalent of what we're currently calling "sub-handlers," yes? I like the idea of a nomenclature change here just to make clearer the difference between the two, and to standardize an approach to driver choice.

Also, regardless of the exact architecture in terms of invocation, I like the idea of moving from the current MultiHandler model to one where all Cache objects utilize a composite handler system of some kind.

Re: Invocation Strategies, why not just inject strategies on the handler level? Attaching decision objects (that provide tests on factors like data size, ttl length, etc.) to each handler could allow us to create complex caching behaviors where necessary but still default to the current stacked behavior (store everywhere, retrieve from first available) without any such input.

from stash.

Driver is indeed the successor of Sub-Handler. There wouldn’t be a uniform interface for them so they can be tightly coupled with the using Handler to be as thin as possible.

The whole Composite/Collection/Invoker layer can be used at will anyway, as CompositeHandler implements the same interface as all the other handlers. So the default behavior could be what we have today.

Re: Strategies on a Handler level. When injecting strategies to handlers directly, they would not know about the other available handlers currently configured so fallback, write-to-all, read-from-first etc. would not be possible.

from stash.

As long as handlers have an ordering, couldn't you implement each of these patterns using a combination of strategies for each, if the CompositeHandler polls each Handler and writes to it if it passes the tests?

Implementing a specific Strategy decoration layer would eliminate the need to maintain an ordering of handlers in the CompositeHandler (since an OrderingStrategy or something would do so instead) but I'm concerned that implementing strategies that apply to all Handlers at once would be less flexible than simple injected logic in each handler.

from stash.

I'm pretty much committed to the use cases you provided, as they make a ton of sense. I like where you're going with things too (ask Josh, the way to win me over on anything is with a good chart- i'd love to know what you used to make that one).

One thing I want to stress is that performance is a huge priority for this project. One of the reasons I've resisted some levels of complexity in the handlers themselves was to ensure they were as quick as possible. The reason I bring it up is that the decoration layer, as Josh calls it, seems like it would be fairly unobtrusive. The extra code would only be called if someone explicitly added the rules in place and in most cases store never happen, since the stuff is already cached. I also feel like this could be made extremely powerful without a significant amount of complexity.

Putting that aside for a second, I'd like to hear a bit more about how this would work- particularly the InvokerStrategy class. I think an example class (a simple one, doesn't have to work or anything) would really help. There are a few other minor question- It seems like the CompositeHandler is simply a more powerful version of the MultiHandler (with a much better name)- I'm a roughly correct in that assumption? Also, is there a benefit to using the ArrayCollection class (which we'd have to pull from Doctrine I believe?) over just an array?

from stash.

One added performance gain: delayed set.. in the context of a web request, there really is little reason to immediately try to save a cached object to backend storage[memcache, apc, file, etc]. Instead use ephermal for all storage, and use the destructor events for the other backends to push the data out. In theory, destructors will be called after the web page data has been flushed to the end user - so you avoid the performance lag of multiple cache save events while still saving the data.

from stash.

These strategies should be worked into PSR-6!

from stash.