1 It gives core a dependency on a third party library that is not found elsewhere. 2 The only implementation is in doctrine SQL. So if we make a MongoDB aclprovider then it should be in core aswell so that a developer can use it out-of-the-box? Also what if someone wants to use Propel for it then it should also be in core since the others are.
The pros to moving it into DoctrineBundle is that the bundle already have a dependency on dbal. And it dosent even require that you use the ORM. So if ACL is in core theres a dependency for Doctrine DBAL in core but also in DoctrineBundle itself. Also the configuration could be easier as the acl system would use the dbal connection specified in DoctrineBundle instead of people have to specify it once more. I can see why this isnt a big problem for people that use the Doctrine ORM/DBAL anyway but i dont and this requires me to use it which in itself isnt very flexible. But if it HAVE to be in core the documentation needs some serious expansion as it is the same with the other parts of the Security component theres is only enough documentation to use it very basically. And if it should stay i say we move all the authentication listeners and proivders for mongodb and doctrine into core. since the dependency is already there and according to Johannes the Security component is self contained. And as a last note. If the ACL system used PDO instead i wouldnt have a problem with it being in core if there was docs on how to extend it. :) -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
