Regarding the “Flow on Symfony” part: I agree with @bwaidelich here - I don’t think that it’s feasible or would make sense for our existing community to start from scratch and implement the Flow feature set on top of Symonfy. Also I don’t think that we should - right now - look further into making Flow a Symfony application (that would mean, compatibility on bundle level).
That being said, we should definitely look into modularizing Flow more and also looking into replacing certain parts of Flow with third-party components. Typical examples would be logging, the HTTP stack and so on. We also should look into taking advantage of Symfony’s tooling, like the profiler.
What’s important to me in that regard is:
we should maintain and further improve the typical Flow developer experience, which means convenience features like DI (property injection …), automatic registration of certain components (command controllers and their documentation for example)
we should make it more natural for experienced Symfony developers to find their way around in Flow
we should replace existing code with third party components which is not part of the special Flow developer experience and is probably better maintained elsewhere (HTTP, our virtual browser, loggging, …)
we should strive for making Flow more lightweight (e.g. an option to use Flow without AOP, look for a solution without proxy class generation, make it possible to realistically create PHAR applications with Flow)
we must make sure to provide a realistic upgrade part for existing Flow projects
I think we should create technical story-tickets (possibly with sub-tasks) for those, explaining the desired long-term outcome in order to prevent situations like:
Well, if you modularize you actually create the possibility to use one of the existing 14 standards… You just need to resist the urge to create the 15th at that point.
Yes, you’re right of course, but facing reality it’s often not as easy I’m afraid.
Take the HTTP subpackage for example: If we’d create an adapter to PSR-7, we’d have to think of a solid migration path including proper documentation or else people will end up using n+1 ways of dealing with it.
This might be very obvious but we’ve seen it failing multiple times in the past and new ways of solving things actually increased confusion because they a) increased complexity, b) weren’t properly documented, c) the previous way wasn’t properly deprecated (not calling names here ;))
we should strive for making Flow more lightweight (e.g. an option to use Flow without AOP, look for a solution without proxy class generation, make it possible to realistically create PHAR applications with Flow)
I don’t think that’s necessary, nor really feasible. A lot of the power of flow lies within the proxying/aop and building a flow distribution without that would feel like an akward attempt to achieve mainstream usability at the probable cost of functionality/performance. Sure, the proxying/aop is not perfect and has it’s drawbacks (everyone at least once needed to double flush caches in order to get things to work as expected again), but I regard it as an integral part of Flow (not the cache flushing ;)).
You just need to resist the urge to create the 15th at that point.