More complex handlers

[lstrojny]

While working on Ephemeral Handler I more and more loved the idea to make handlers more capable to achieve more complex caching strategies and on the other hand to separate concers in Stash\Cache more cleanly. These are the use cases I have in mind:

• Store in Memcache only (currently achievable by disabling memory storage in Stash\Cache and using Memcache handler)
• Size bases balancing: Store small entries in APC, large ones in Memcache (currently not possible)
• Overflow based balancing: store everything in APC but overflow to Memcache (currently no possble)
• Any combination of those use cases

Architecture overview:

• We split handlers into three layers: invocation strategies (the "what is invoked"), handlers (interacts with the caching store) and drivers (abstracts client differences for Memcache vs. Memcached, Predis vs. PHP Redis)
• A CompositeHandler uses an InvocationStrategy to call instances of HandlerInterface. InvocationStrategy works on a HandlerCollection and decides what instance of HandlerInterface needs to be called and calls it
• A Handler may use a Driver to do it’s work

Here’s some pseudo code:

<?php
namespace Stash\Handler\InvokationStrategy;
interface InvocationStrategyInterface
{
    public function invoke(HandlerCollection $handler, $method, array $params = array());
}


namespace Stash\Handler;
class HandlerCollection extends ArrayCollection
{
    public function add($name, HandlerInterface $handler);
    public function get($name);
}


namespace Stash\Handler;
class CompositeHandler implements HandlerInterface
{
    public function __construct(InvocationStrategyInterface $invocationStrategy, HandlerCollection $handler);
}

And here is some UML:

[jhallbachner]

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

[lstrojny]

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.

[jhallbachner]

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.

[tedivm]

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?

[Deleted user]

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.

[CMCDragonkai]

These strategies should be worked into PSR-6!