attendees: fabien, kris, dustin, jeremy, johannes, jon, jordi, lukas, bernhard, nils disclaimer: most of the decisions where not unanimous. after all all "easy" and "obvious" decisions have long been taken.
1) core bundle names
we agreed to prefix all core Bundles with "Symfony" to follow our general best practices. it was noted that this would lead to requiring a "symfony_" prefix for the Bundle configuration in the config.yml. many people said while it might seem ugly at first sight, we will all quickly get used to it. kris however said he could make it possible to make the alias overwrite-able, which would mean no change is necessary. however there was no agreement if we should then make use of this for core Bundles.
we basically agreed that the main reason for bridges is to send the message that while the core dev team might not maintain all different backends and supporting layers, but that if someone else comes along and submits a solution (f.e. Propel support for the form layers), then it can get "equal" visibility. we discussed how to organize the bridges. since the main point is to separate "bridge" code for code and maintenance separation the actual structure isn't super critical. aka is X inside the Y bridge or vice versa. the main driving point is who maintains the code especially since each bridge will not have that much code. furthermore its in theory possible to have a need for a bridge that covers 3 or more dependencies at once at which point the bridge name becomes either arbitrary or we have to create a bridge for each permutation. we also briefly discussed naming but in the end we stuck with bridge. We also agreed that the purpose of bridges cannot be to blindly extract each and every dependency into a bridge.
To summarize: We decided to create a new Bridge subnamespace where classes are stored primarily by the third-party library like Symfony\Bridge\Doctrine\Form\...
we agreed to add interfaces where it makes sense. for example for "request" and "response" we agreed that there isnt really a need for an interface. for one there shouldnt be a need to mock these classes as these classes are for the most part just data containers anyway. so if there is interest in integrating with some other framework's "request" class for example its more feasible to either use composition or just write a converter.
4) overwriting bundle parameters
we agreed that we would specify in the documentation that anything specified in config files while technically overwriteable they are not to be considered extension points. therefore anything that should be configurable in a Bundle should be explicitly exposed in the Bundle's configuration. we also discussed if we should remove unnecessary use of parameters (like parameters for class names which are not meant to be configurable). there was a bit of back and forth here. one side was to discourage users from shooting themselves in the foot (aka those who do not care about the warning that we do not maintain BC in things not exposed in the config), while others said they might still want to do and just deal with BC breaks as they occur (which should not be too often). in the end there was no clear agreement if its enough to just warn users in the docs or if we have to prevent users from "shooting themselves in the foot" by going through all the xml configs to remove unnecessary parameters, thereby preventing users who accept the BC break risk from easily overriding internals.
5) protected vs private
here we agreed that it would be better to close down the API to just the extension points we want to support explicitly. then if users can bring forth good uses cases to further expand the extension points we will relax things from private on a per use case basis. the lieutenants will handle locking down things in their components and fabien will handle the rest
this was briefly discussed and it was decided that things will stay as is, aka not FQN when referencing Bundle resources, since its just ugly and we changed things for good reasons before.
7) eager response
this generated a lengthy discussion. some argued that eager response was good regardless of how we deal with the issues with remember me in the security layer. in the end the decision was to provide a way to set them some where else than the reponse, but we did leave the actual implementation open (at the moment, we have two alternatives, but maybe Kris and Jon have some more ideas).
8) doctrine event manager
we briefly discussed adopting the doctrine event manager as it makes things more explicit making it more IDE friendly and also reducing the code needed to process the results of events. the code is about equal in size and even while creating instances of eventarguments might add a tiny bit of overhead, the reduction in result processing code should mean that performance should be about equal. we still need to figure out how to deal with a mandatory dependency on 3rd party code. then again the code hasnt changed much in a long time, so we might just duplicate it.
Here are the topics that we didnt discuss:
9) default scope
Lukas only briefly discussed this with kris, who said he spoke to fabien about it before. we agreed to make all core service scope's explicit (aka where we currently do not specify a scope we will explicitly specify "container"). then we will automatically attempt to determine the scope for user defined services without an explicit scope. anything that gets the container injected will default to "prototype" to minimize the user shooting himself in the foot.
10) subrequest security
Here Lukas talked to Johannes a bit, we agreed that in case we do not implement in security for subrequests, then we need to remove the controller based security configuration in the config.yml. People that do need security for subrequests will then need to manually implement the checks (which should be fairly easy with SecurityExtraBundle?). I also talked to Johannes about that if we do secure subrequests we need to deal with the fact that it would add a fair bit of overhead to move the security services to scope request. So either we would need to add facilities for the security services to manage a stack of states (aka a special "optimized" approach to managing request scope). Alternatives Jordi has stated that with ESI, this becomes irrelevant anyway as ESI "subrequests" will effectively mean that all subrequests will be done in their own master requests. in other words its not worth it to try and optimize the security in subrequests and we might as well just move them all to request scope.
11) cmf and phpcr odm namespace
Here for me the main question is if DoctrinePHPCRBundle will be in Symfony just like MongoDB or if its also in Symfony\CMF.
Jon adds: "Won't this be solved by the packaging and distributions? The DoctrineBundle? and DoctrineMongoDbBundle? would be available in the Doctrine distributions. The bundles themselves could really live in any namespace, and could be in any github repository. We'll just have distributions that combine the different bundles to create different distributions. I assume we'll have some kind of web interface or something where you could choose from preconfigured distributions from us or they could build their own by choosing the bundles they want."
12) form rewrite
Seems like we will move forward with this.
13) flash messages and ajax (remove on read)