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

Yeah, this perfectly summarizes what I managed to put in way too many
words. Thanks, Larry :-)

On Nov 27, 2016 19:33, "Larry Garfield" <la...@garfieldtech.com> wrote:

> 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 a topic in the
> Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/php-fig/kSj_yVbkwOw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/php-fig/f910ab9a-ed94-e66d-8f69-08b816d130e9%40garfieldtech.com
> <https://groups.google.com/d/msgid/php-fig/f910ab9a-ed94-e66d-8f69-08b816d130e9%40garfieldtech.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CADqTB_jOkXiN1UdLL-WFigPUeVhfN1xOuWUPMPQ-gXE%2BbiAB%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to