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/simplecache/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-2738-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_gx8bysGMiQ5uep7jWE4XS8rCiz9%2BjhypjKWqOPJurZ5A%40mail.gmail.com
<https://groups.google.com/d/msgid/php-fig/CADqTB_gx8bysGMiQ5uep7jWE4XS8rCiz9%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 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/0b5cb48a-48c9-c8a9-c178-7eafe8c16d78%40seld.be.
For more options, visit https://groups.google.com/d/optout.
