Go Back   HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials > ISPConfig 3 > Developers' Forum

Do you like HowtoForge? Please consider supporting us by becoming a subscriber.
Reply
 
Thread Tools Display Modes
  #1  
Old 15th February 2011, 07:28
vStone vStone is offline
Junior Member
 
Join Date: Feb 2011
Location: Belgium
Posts: 15
Thanks: 1
Thanked 4 Times in 3 Posts
Lightbulb Idea: Split out apache2 plugin.

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.
Reply With Quote
Sponsored Links
  #2  
Old 15th February 2011, 10:03
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lneburg, Germany
Posts: 36,373
Thanks: 833
Thanked 5,478 Times in 4,313 Posts
Default

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.
__________________
Till Brehm
--
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.
Reply With Quote
  #3  
Old 15th February 2011, 13:56
vStone vStone is offline
Junior Member
 
Join Date: Feb 2011
Location: Belgium
Posts: 15
Thanks: 1
Thanked 4 Times in 3 Posts
Default

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.
Reply With Quote
  #4  
Old 15th February 2011, 14:53
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lneburg, Germany
Posts: 36,373
Thanks: 833
Thanked 5,478 Times in 4,313 Posts
Default

Quote:
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.
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.

Quote:
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, ...).
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.
__________________
Till Brehm
--
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.

Last edited by till; 15th February 2011 at 14:55.
Reply With Quote
  #5  
Old 15th February 2011, 15:07
vStone vStone is offline
Junior Member
 
Join Date: Feb 2011
Location: Belgium
Posts: 15
Thanks: 1
Thanked 4 Times in 3 Posts
Default

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
Reply With Quote
  #6  
Old 15th February 2011, 15:26
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lneburg, Germany
Posts: 36,373
Thanks: 833
Thanked 5,478 Times in 4,313 Posts
Default

Quote:
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
This is not a channel of the ispconfig project. We neither own that channel nor know the owner.
__________________
Till Brehm
--
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.
Reply With Quote
  #7  
Old 15th February 2011, 17:25
vStone vStone is offline
Junior Member
 
Join Date: Feb 2011
Location: Belgium
Posts: 15
Thanks: 1
Thanked 4 Times in 3 Posts
 
Default

Quote:
Originally Posted by till View Post
This is not a channel of the ispconfig project. We neither own that channel nor know the owner.
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
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
ISPConfig 3.0.1.4 causes Apache to have too many open files gkovacs Installation/Configuration 29 27th February 2013 08:59
Spamassasin markasjunk2 roundcube plugin HyperAtom General 1 17th November 2012 20:19
Whole server went down wxman General 25 28th September 2012 18:32
Spamsnake - Problem with spamassassin, FuzzyOcr and MySQL debuguser HOWTO-Related Questions 6 16th September 2008 18:37
Spamassassin not working hairydog2 General 7 12th July 2008 21:15


All times are GMT +2. The time now is 12:13.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.