ok, will try to put in a PR for that tomorrow :-)


On Tue, Nov 29, 2016 at 2:21 PM, Jordi Boggiano <[email protected]> wrote:

> Yes PSR-16 is meant to live alongside PSR-6, so it has to be reasonably
> compatible and yes a bridge has been done (https://github.com/php-fig/si
> mplecache/commit/13f43ba7f6d5ce37c6c115c26a5f653c2d9c1e18). I agree it
> shouldn't sound like it depends on PSR-6 though. If you have ideas how to
> clarify the wording PRs are welcome :)
>
> Cheers
>
>
> On 29/11/2016 09:52, Rasmus Schultz wrote:
>
>> This is an application concern IMO, much like the management of
>>>
>> multiple cache pools, etc.
>>
>> Yeah, for some types of cache-servers, flushing expired entries
>> on-demand may not even be a thing - so this is likely outside the scope
>> of what should be interoperable, as this kind of functionality is
>> implementation-specific.
>>
>> Oh, and here's a simple flat-file cache-implementation:
>>
>> https://github.com/kodus/file-cache
>>
>> It's complete, but will of course change with the coming interface
>> updates.
>>
>> I don't know if there are any other flat implementations of PSR-16 cache
>> out there? I don't see any on Packagist. So this might be helpful as a
>> real-world case.
>>
>> One other thing, about the documentation and meta... it all sounds like
>> PSR-16 was designed to be a layer on top of PSR-6? It almost sounds as
>> though PSR-16 *depends* upon PSR-6?
>>
>> That seems really wrong. I mean, PSR-16 is complete within it's own
>> scope, and has no dependency on PSR-6 whatsoever - it's perfectly
>> feasible to make PSR-16 libraries stand alone.
>>
>> I think it's great if the meta/doc states that it was designed with
>> PSR-6 compatibility in mind, making it possible to bridge PSR-6 to
>> PSR-16, but both the doc and meta at the moment make it sound like
>> that's it's only purpose...
>>
>> I personally view it as a simple alternative to PSR-6, not a layer that
>> I'm going to put over it. (I don't want to hide complexity - I want to
>> remove it and simplify.)
>>
>> Has a PSR-6 to PSR-16 bridge been implemented?
>>
>>
>> On Mon, Nov 28, 2016 at 10:00 AM, Jordi Boggiano <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>     On 28/11/2016 09:51, Rasmus Schultz wrote:
>>
>>         What about garbage collection?
>>
>>         I know that some cache-servers may take care of this
>>         automatically, but
>>         for something like a file-based cache, it needs to get triggered.
>>
>>         Is it just left up to each implementation to take care of this in
>>         whatever way they need to?
>>
>>
>>     Yes :) This is an application concern IMO, much like the management
>>     of multiple cache pools, etc.
>>
>>     If you read again my post from 4 years ago [1], PSRs I find are
>>     largely beneficial for libraries and not for
>>     frameworks/applications. Applications are in control, but libraries
>>     have no control and are dropped in random contexts. It kinda bums me
>>     out that many still don't seem to understand that (or just don't see
>>     it that way?).
>>
>>     It's unfortunate that FIG has framework in its name because it is
>>     highly misleading, but down the line Framework-level
>>     Interoperability means having interoperable libraries more than
>>     frameworks being able to interact with each other.
>>
>>     [1] https://seld.be/notes/one-logger-to-rule-them-all
>>     <https://seld.be/notes/one-logger-to-rule-them-all>
>>
>>     Cheers
>>
>>     --
>>     Jordi Boggiano
>>     @seldaek - http://seld.be
>>
>>     --
>>     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
>>     <https://groups.google.com/d/topic/php-fig/kSj_yVbkwOw/unsubscribe>.
>>     To unsubscribe from this group and all its topics, send an email to
>>     [email protected]
>>     <mailto:php-fig%[email protected]>.
>>     To post to this group, send email to [email protected]
>>     <mailto:[email protected]>.
>>     To view this discussion on the web visit
>>     https://groups.google.com/d/msgid/php-fig/13388408-c187-2738
>> -7940-1084f473be5b%40seld.be
>>     <https://groups.google.com/d/msgid/php-fig/13388408-c187-273
>> 8-7940-1084f473be5b%40seld.be>.
>>
>>     For more options, visit https://groups.google.com/d/optout
>>     <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 [email protected]
>> <mailto:[email protected]>.
>> To post to this group, send email to [email protected]
>> <mailto:[email protected]>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/php-fig/CADqTB_gx8bysGMiQ5
>> uep7jWE4XS8rCiz9%2BjhypjKWqOPJurZ5A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/php-fig/CADqTB_gx8bysGMiQ
>> 5uep7jWE4XS8rCiz9%2BjhypjKWqOPJurZ5A%40mail.gmail.com?utm_
>> medium=email&utm_source=footer>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Jordi Boggiano
> @seldaek - http://seld.be
>
> --
> 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/to
> pic/php-fig/kSj_yVbkwOw/unsubscribe.
> To unsubscribe from this group and all its topics, 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/ms
> gid/php-fig/0b5cb48a-48c9-c8a9-c178-7eafe8c16d78%40seld.be.
>
> 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 [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/CADqTB_gzgDhFUjv9XgRz96kOo7BniEeyAub1XZqDMT-yZmp81g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to