> 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]> 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 > > 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/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/13388408-c187-2738-7940-1084f473be5b%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_gx8bysGMiQ5uep7jWE4XS8rCiz9%2BjhypjKWqOPJurZ5A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
