I believe this hasn't been discussed already with the community (@ the forums), and there's not really an appropriate thread already so it seems, so I'm starting a new discussion :)
I watched (well, the first part anyway.. ;-)) the latest Google Hangout (https://www.youtube.com/watch?v=c5J5i31UaPY) and wanted to give my feedback concerning the module separation.
In the hangout @niden is talking about plans of dividing the Phalcon PHP module into 2 parts; 1 core, and 1 'extensions' So the core won't be so big, and extensions can be added when needed.
Immediately what to my mind came was: why not separate the extensions further? It might happen that you only need 1 specific extension (eg. Postgres support), and then you have to add the complete extension module. Kinda all-or-nothing. It seems to me that is a kind of the same issue then in respect to this question of splitting stuff up?
I guess the only disadvantage would be the maintenance overhead when splitting stuff up into a multitude of extensions? Of course the advantage: smaller footprint, bigger modularity.
And regarding the DB-connector example; instead of leaving MySQL in the core, I would put that in a separate extension as well? Why leave that in, and make, perhaps, a biased decision? (Ok, sure, it's the most used DB, but it's nice when you're not using it, perhaps if you do use Postgres, you can leave it out.)
IMO would be great, if you're going this path, Phalcon core could really be mean & lean, and one could just pick his/her required extra's.. (just like PHP itself I guess)
Love to hear your feedback. :)
Cheers!
