On 11/27/2016 06:20 PM, Rasmus Schultz wrote:
> As I understand what you said, PSR-16 represents a cache server, and
flush() would wipe everything on there.
I find this answer highly problematic, because that means that there
is *no* concept to support back-ends that can (efficiently or not)
support multiple collections.
*snip*
A server-abstraction *precludes* implementations that support multiple
collections - a clear() method, by definition, would clear the
contents of the *server*.
Compare this with a collection-abstraction, where a clear() method, by
definition, clears the contents of the *collection*.
The latter does *not* prevent you from having a collection that
happens to be a server.
The former *does* prevent you from having a server that supports
multiple collections, which just isn't the reality we have.
I largely agree with Rasmus here, although the difference is very subtle
and likely no more than one or two words in the spec.
PSR-6 used the "pool" concept rather than "server" specifically for this
reason; each "pool" is a separate logical namespace independent of any
other pool, and two pool objects should not interact. They could both
be backed by a file system (separate directories), or by the same SQL
database connection (separate tables), or entirely separate Redis
servers, or the same Redis server with automatic prefixing... that's all
an implementation detail. At a logical level they're independent
collections.
PSR-16 should follow the same assumption. In practice I don't think the
spec need change for that, or if it does only by a word or two somewhere
when discussing what the object represents.
Disclaimer: I am largely approaching PSR-16 as a "streamlined" interface
atop PSR-6, via a standardized bridge, as I expect that to be the
typical use case. For that reason, most underlying semantics can and
should be borrowed from PSR-6 directly, as we already figured those out
at length and those aren't the parts people had issues with. :-) So my
default position on most questions for PSR-16 is "do as PSR-6 does,
unless there's a compelling streamlining reason to do otherwise." I
think that will give the most usable and easiest to implement end-result.
--Larry Garfield
--
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/f910ab9a-ed94-e66d-8f69-08b816d130e9%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
