Personally, I advocate maximum reuse of existing (and proven) solutions. That's why I've choose symfony (with a lowercase s) 6 years about to develop our current LMS, and that allows our very small team (2 people) to have a working solution that, while not being as complete as chamilo, has been sufficient for 4 years.
I will also add that I understand the goal of Chamilo is to support open-source e-learning, so our role is not the reinvent everything that is not directly tied to e-learning but to build efficient e-learning tools. As our resources are limited, I think we should focus on things that are specific and important to elearning (SCORM, courses management, portfolio, etc.), the same way Ubuntu focuses on user experience and based its effort on the proven Debian distribution. So I'd say that build on a proven framework seems to me a good solution. That being said, my preference would go to Symfony2 because : * I've work with symfony1 ;) , and even if there's no compatibility between to two, I recognize myself in the way the framework evolve (Symfony2 is essentially a PHP port of the Python framework django that is my preferred environment) * Beside the code quality, the main reason I've chosen Symfony was the documentation. I don't know if it change but at the time ZF doc was very poor. About speed (and quality in general): Symfony2 has became one of the two major frameworks and some of their developers are (or have been) PHP core developers. So most of time, I don't how we can write better code than them. They have also done an interesting work on caching [1] and on distributing their bundles (which can be interesting for our package manager) About the codebase size: I don't really see what the problem is. Even if Symfony2 is a quite big project, it's just dozen of Mb, nothing really important those days. On the other side, Symfony2 is not really sized to run on free web hosting which may be a problem (but not for me) Also Symfony assumes that you have access to CLI on the server (or at least, it really help) Another aspect is that I think we should not included the framework in the project but create a project that relies on the framework, to facilitate code updates (at least with minor versions) For example, the eFront LMS is based on the ZF, but the last time I've check I notice it included a quite old release. About the freedom: the main problem is if one day the Symfony2 project goes in a direction that is not the Chamilo's one. Or just if the project evolves faster than we can follow. This is one of the problem we face with our current LMS, that is blocked with symfony 1.0 and Propel1.2. But I would say that the structure of the framework (a bunch of components that adheres to the "loose coupling, tight cohesion" [2], another thing "stolen" from django) allows us, if one component goes in a direction that doesn't fit our needs, to replace it (even if it doesn't completely remove the problem of the cost of this replacement) About the licence, IANAL but I would say that include a BSD licensed project within a GPL3 one is not a problem (opposite to the contrary.) Like Yannick, I think one of the major questions would be how to handle the migration. It has to be as smooth as possible. I know that Sensio, the company behind Symfony2 has already done such migrations for some customers (DailyMotion has migrated from a custom PHP framework to parts of Symfony2, the front controller and the routing being the first steps). I've also read a presentation[3] about how to migrate from symfony 1 to Symfony2 : it's quite general but it give some clues about how to do this. > Furthermore, we increase the likeliness of having > developers with Zend/Symfony experience getting into our project, which > couldn't be bad. Also agree. Regards, Goulwen [1]: http://www.slideshare.net/fabpot/caching-on-the-edge-with-symfony2 [2]: http://c2.com/cgi/wiki?CouplingAndCohesion [3]: http://www.slideshare.net/marchugon/quid-de-vos-applications-symfony-1/ _______________________________________________ Dev mailing list Dev@lists.chamilo.org http://lists.chamilo.org/listinfo/dev
