Hey list!
PSR-11 has been accepted so we have standardized how to fetch entries from containers. The next logical step is to find a common way to put things into a container. More generally, the goal we are seeking is to make it possible for a package author to provide/modify entries in any container (rather than having to write a module/bundle for each framework as it's the case today as I described in this talk: https://thecodingmachine.github.io/forumphp2016talk/index_en.html#60). Let's be clear that the goal is NOT to define a single way of configuring a container. Each container has its own strategy (configuration files, autowiring, PHP code...) that makes it worthwhile. What we are trying here is to find an additional *shared* way of putting things into a container specifically for package authors. Because it's almost impossible for package authors to write a bridge for every framework out there). Also, since FIG 3.0 has passed, it's time that we officially create a working group. As a reminder, we (the container-interop participants) explored several strategies: - unified file format - common interfaces for container definitions - common interfaces for dumping PHP code representing container definitions - service providers I have summarized this in those 2 blog posts: https://www.thecodingmachine.com/psr-11-an-overview-of-interoperable-php-modules/ and https://www.thecodingmachine.com/psr-11-get-ready-for-universal-service-providers/ . The conclusion we reached was that standardized service providers are the way to go. Among many criteria, they are easy to write, and if done right, can be properly optimized by compiled containers. We started working on it at https://github.com/container-interop/service-provider/ Work is well advanced: we have prototype integrations available with the major frameworks out there. There is still a lot of work to be done: - Recently, Rasmus Schultz came up with an alternative proposal. The idea is that rather than trying to provide factories to the containers (what service providers do), a module could provide its own container and publish to the "main container" the list of entries it contains. Rasmus detailed the idea here: https://github.com/container-interop/service-provider/issues/40 . This idea looks a bit like the "delegate lookup feature" that was removed from PSR-11 in the philosophy (several containers running side-by-side), but is different in the implementation. I'd be interested to gather feedback from the community on Rasmus' proposal (I suspect it might be complementary to container-interop/service-provider rather than opposite) - With the current proposal, we can already add services and extend existing services. We need to know if we want to be able to do more (like adding/extending services conditionally based on the container's configuration). More generally, we need to discuss the exact scope of the PSR (limited to simple use cases? extended?) - Finally, there will be a huge amount of work waiting for us in the nitty-gritty (exceptions handling, etc...) I'm hereby calling *interested members to step up* to create a working group, and for member projects to give as much feedback as possible. PSR-11 has made a big leap forward in the very last days because "big players" joined the party a bit late :). For this PSR, it would be great to have some feedback from you guys early on in the process. ++ David. Twitter: @david_negrier Github: @moufmouf -- 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/1573992a-355d-42a8-bd1f-c53ebaa43fd1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
