Hey Jordi,
This is pretty exciting - and we're already using PSR-16, so it's good to
see this nearing completion :-)
I have a question about the design, however - to which I did not find an
answer in the doc or meta-doc.
PSR-16 does not support the concept of multiple cache collections.
First, let me say that I think this is the right decision - supporting
multiple connections with a single cache service seems to imply that a
single cache service can serve all caching purposes, for all consumers,
centrally, in your project, which, I believe, is false; it implies that
there's a single "right" cache for all consumers, which isn't true.
For example, a cache for a few thousand small user-records might require a
very different type of cache from one that caches millions of rendered
articles - so I don't actually want the convenience of a global cache, I
want to be forced to make decisions about caching for each consumer based
on what's relevant to each of them.
However, I also don't want to set up a new cache server for every consumer.
I likely do have several consumers that need to store cache-data in a
shared Memcache server.
I also don't want each consumer to have to worry about prefixing key or
something - which, even if every consumer took care to prefix keys, a
single PSR-16 cache instance still can't serve multiple consumers, because
I'd be unable to, say, clear the small collection of cached user-data
without also clearing the enormous multi-million cache of rendered articles.
So the concept of multiple collections ("pools" in PSR-16) is necessary.
Since there is no collection-concept in PSR-16, I have to assume that the
intent is for each cache-instance to host a single collection of
cache-entries? (and for the reasons describe above, I think that's the
right approach, and it matches the reality of making caching-decisions much
better than PSR-6.)
Assuming I understand this correctly, I think it's really important to
describe that concept in the document, or at least in the meta.
Assuming the idea is to have multiple cache-instances, that of course
doesn't prevent you from backing them all with a single Memcached server -
it's just a matter of having the right constructor signature, e.g. one that
includes a collection prefix, so that multiple PSR-16 cache-instances can
host collections on the same physical Memcached server, without, for
example, key collisions, and without calls to clear() on one instance
affecting the other.
For something like a flat file-cache, this is extremely easy to follow and
implement - it's probably harder for something like Memcached
I guess I'm looking for a clear definition of what the PSR-16
cache-abstraction represents: a cache *server* or a cache *collection*?
The distinction is *extremely* important for the definition, implementation
and understanding of, for example, flush() - compared with Doctrine cache,
am I flushing the contents of the entire server, as in Doctrine's flush(),
or am I flushing the contents of a collection of cache-entries on the
server, as per Doctrine's deleteAll()?
Assuming I understand the concept correctly, I would *not* expect a
cache-instance to flush the entire server, but rather to flush only the
collection represented by the cache-instance.
Doctrine's cache-abstraction includes the concept of "namespaces", which
equate to collection IDs - but here the distinction is clear, since it
includes two distinct methods for clearing a collection with deleteAll() vs
clearing the entire server with flush().
With PSR-16, there is only method, flush(), so it's extremely important we
understand what precisely the scope of a cache-instance is: a entire
server, or a collection on a server?
- Rasmus
On Wednesday, November 16, 2016 at 3:22:20 PM UTC+1, Jordi Boggiano wrote:
>
> Heya,
>
> We believe PSR-16, Simple Cache, is now ready for final review. As
> coordinator, I hereby open the mandatory review period prior to a formal
> acceptance vote; voting will begin no earlier than December 1st, 2016.
>
> Here are links to the most current version and its meta document:
>
>
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md
>
>
>
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache-meta.md
>
>
>
> The package containing the interfaces is there:
>
> https://github.com/php-fig/simplecache
>
>
> The latest important changes to the interfaces can be found at:
>
> https://github.com/php-fig/simplecache/releases/tag/0.2.0
>
>
> And FWIW, Scrapbook already provides a PSR-16 implementation in its
> upcoming release:
>
> https://github.com/matthiasmullie/scrapbook/blob/master/src/Psr16/SimpleCache.php
>
>
>
> Thanks for your time reviewing!
>
> Cheers
>
> --
> Jordi Boggiano
> @seldaek - http://seld.be
>
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/d803ca3d-2cd0-46e8-9967-6462f2ea7ee1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
