Hi, I've been scrolling through the forums and noticed that a lot of people want support for X or Y programming language. Lets say.... python for example. At this moment, this means hacking our way into the apache2 plugin. I would suggest (and partly volunteer if I find enough time) to split out plugins and implement a more generic hook system allowing plugins to hook into eachother. This way, we could easily split out configuration of a vhost depending on what 'addons' the user has selected. My plans for the moment are: 1. Implement a minimalistic hook system to allow 'addons' to hook into apache2. This by exploring the plugin class and see how it would all fit together. Plugin hooks are different from how the module registeres events (and calls them) as they will return a value/string/array/.... that can be used by the plugin. 2. Implement a way for 'addons' to generically store their configuration in the database. Now, all configuration is stored in the web_domain database, meaning, we have to adjust the schema each time we add support for a new 'language' or other apache feature. I was thinking of serialize/de-serialize. Other options would be to use JSON. Also: addons should be able to override the default configuration loading by overloading load_configuration($domain_id) and save_configuration($domain_id, $config_array). 3. Migrate current apache2 features/languages to use this new system * PHP * Ruby * ... 4. Document everything 5. Add support for additional stuff like python through mod_python and/or mod_wsgi. I'm not sure how long it will take me and how much time I can free up for this rather... thorough change. But before I even started, I wanted to hear some opinions on this approach. It would drastically simplify adding new apache features / expanding apache features imho.
The main problems that I see with this approach is the interface part. Every function that you want to add needs different input fields in the interface, so for every function that you want to add there have to be added fields into the interface template and interface logic as well. Then you might have to add limits for these feature sin the client and reseller templates as well etc. plus the logic to enforce them. Also there are not many features that were missing, mostly jsp, ruby on rails and python support. In my opinion it might be enough to just clean the code of the apache plugin and split it into sub functions. Storing the settings into a serialized array makes it much more complicate to change them naually in the database and to update them. I fear that using such a storage model will limit the ability for easy updates in future.
Making this conversion will add a lot of overhead / abstraction which I am aware off. I must agree with the it will make updates more difficult. The only other option I see is when the complete database system migrates to some kind of schema-based updates. (I saw a ticket about that in the bug tracker 'somewhere'). Or a more generic way of storing key-values in the database. For the interface, we could adjust the backend so it can advertise what addons are available and supply a generic way of managing fields / configuration (text, boolean, numbers, ...). We'll also have to abstract limitations/permissions as you pointed out, but this can not be a blocker imho.
ISPConfig has already a new database update system since 3.0.3 which allows custom columns in database tables. So the posts in the bugtracker about that are obsolete. I know that this programming model sounds smart and I did the mistake to use this as we developed ispconfig 2, but it has prooven to not work for a OS project with many developers. We had such a system in ispconfig2 incl. storing the document description as serialized object. This caused more and more problems over the years which resulted in the decision to not use the codebase of ispconfig 2 for ispconfig 3 and to not use such a development model. So I dont want to add a technique again to ispconfig 3 which has been proven to not work for us. If you have a lot of external developers and you work with this kind of serialized blobs, you can not merge them with normal svn tools etc. So this dev model might work for a project with a single developer but it does not work for a os project like ispconfig. We had to learn that already the hard way. I'em aware that the apache plugin needs some work and that it might be good to split the code into separate subfunctions. But storing everything in serailized blobs or using key-value tables is not an option in my opinion.
I'll look into the new database update system before anything else. And try to think of other better ways of storing configuration in the database. PS/OffTopic: Is there a specific reason why #ispconfig @ freenode is invite only. I read a couple of posts from a couple of years back that the channel is not used by devs... If this is the only reason the channel is invite only, Maybe putting a statement in the topic of not having devs or giving support would suffice This would allow ispconfig-users to hog n flog together nevertheless
http://freenode.net/group_registration.shtml channel has been inactive for over a year. maybe the project should grab it or at least try to
