Google Summer of Code 2010

This is the first time ispCP is participating in theGoogle Summer of code. The Google Summer of code is a project sponsored by Google to bring students and organisations creating free or open source software together. Google Summer of Code starts on May 24 and ends on August 20.¹

ispCP participates with the following topics all related to ispCP Omega. Good skills in PHP, Perl, HTML are required. Skills in JavaScript, CSS and AJAJ (Asynchronous Javascript And JSON) are good for some topics

Own ideas are highly appreciated.

A small team of developers started a third party application that should become part of ispCP Omega: The Applications Installer (short App-Installer). The App-Installer is a tool that allows to install 3rd party software via ispCP Omega on the client's webspace with a few clicks. The current status of the App-Installer is the Release-Candidate state. Before the application can be integrated into ispCP it has to be tested and the code has to be checked against the Coding Standard and security Standards.

Associated Tasks

• Code Review
• Code Tests
• Function Tests
• Installation, Configuration, Update and Removal of 3rd party Applications
• Documentation of the App-Installer
• Documentation of the 3rd Party Package creation
• Security Policy for 3rd Party Package Repository

The current engine code is written in old fashioned Perl functions. Some of them with redundant functionality. Most of the parts are inherited by ispCP Omega's parent project VHCS. We would like to port the current code to a new MVC style. Therefore, we need a refactoring in three steps:

1. Rename methods and variables after their functionality
2. Move methods to more appropriate locations (e.g. into common function classes)
3. Create Interfaces to abstract from specific services

The current source is mostly coded in old PHP function style. These parts are mostly still part of the parent project VCHS. We would like to port the current functional code to a new MVC style. Regarding the quality assurance, the main controller functions should be tested by PHPUnit test cases. The refactoring should be done in the these three steps:

1. Rename methods and variables after their functionality
2. Move methods to more appropriate locations (e.g. into common function classes)
3. Create objects and assign functions to them

Associated Tasks

• Select/create MVC basic framework. Skills: PHP, knowledge of key frameworks; Severity: medium
• Create MVC parts for reseller, administrator, customer. Skills: PHP; Severity: easy
• Create TestUnits. Skills: PHP, PHPUnit Test; Severity: medium

The current ispCP Omega's templating engine (so called pTemplate from VCHS) is easy to understand but hard to maintain. Therefor we decided to move the templating engine to one of the standards for PHP. Smarty is a well-known template engine since many years. The possibility to make own extensions (modifiers, plugins, …) is one of the key features for us.

Client side validation and informations should be an advancement for the user. jQuery is a lightweight cross-browser standard JavaScript library that will fit our benefits. By the creation of new controls via Smarty plugins, we want to create a solid and friendly user interface.

The current theme has old style HTML syntax with nested tables. The new theme is state-of-the-art CSS and W3C validated code, but is not available as template files.

Associated Tasks

• Create ispCP Omega Smarty plugins (controls, modifier, …). Skills: Smarty development; Severity: medium
• Select/integrate jQuery extensions. Skills: jQuery usage; Severity: medium
• Create template files of new theme. Skills: HTML, CSS; Severity: easy

The current ispCP Omega's backend system is specifically engineered to fulfil the requirements of a common (idealized view of an) Internet Service Provider. Although this approach has been proved effective throughout the multiple ispCP releases, our users are steadily asking for improved flexibility of our software stack. This is, they demand our software to be able to adjust to their specific needs, instead of forcing them to adjust their offerings to those designed by our team.

Thus, our efforts are now geared towards the implementation of a software stack that allows for an easy customization of the offered hosting services. This includes, but is not limited to:

• Ability to choose between different implementations of the common services (HTTP, SMTP, POP/IMAP servers)
• Customized accounting system according to the self defined rules (tracking of mailbox quotas, aggregated total traffic limits, etc.)
• Easy automation of processes (check for failed mail deliveries, customization of PHP directives, management of multiple servers through a single control panel, installation of common software packages, migration of a single account between servers, etc.)

To realize this goals, we envision a system based on a Service Oriented Architecture (SOA), composed of multiple modules, where each module provides a well-defined functionality. Although there is an unavoidable link between hosting services defined by their interdependences (e.g.: DNS authorities depend on the mail service, whereas the mail service depends on the DNS), we aim to trim such dependencies down to a bare minimum. This “bare minimum” common ground will be provided by the base system. Thereafter, each functionality will be managed by a specific module, and these modules will be extremely loosely coupled. Therefore, ISPs will be able to choose the approach that best fits their needs among several options, or even implement their own when needed.

The new backend system (platform) should be able to:

• Manage the available modules (configuration, dependencies, operational interleaving)
• Ease the development of modules (relieve error handling, synchronous and asynchronous task execution, unified configuration handling)
• Fulfill strict security requirements, as some operations must run with root privileges.

This new backend engine must be implemented in either Perl (which has a good compromise between efficiency and ease of use, and has been used in other parts of ispCP) or PHP (most ispcp devs are proficient with it, easing maintenance and future improvements).

Finally, the backend's capabilities should be demonstrated by providing two basic modules to manage (1) e-mail accounts, and (2) DNS entries in their simplest form (no forwarding, no mail relaying, etc.).

Associated Tasks

• Create entity-relationship model
• Create UML class diagram
• Implement backend system

==== UML Design of ispCP Omega ==== For current ispCP Omega development a lot of knowledge about the available functions is necessary. To enhance the degree of re-usability and created dedicated objects in a SOA based environment UML diagrams should be created. The student should create diagrams and models of the current stat (“as-is”) of the Software. Associated Tasks * Create UML activity diagrams * Create UML use-case diagrams * Create entity-relationship model
===== How to apply ===== Wait until March 29 and register until April 9!¹ - Go to the Google Summer of Code 2010 page - Log in with your Google account (or create one) - Register as a Student - Submitting Your Proposal for ispCP - Getting Selected by ispCP - Participate in 2010's Summer of Code, get a cool T-Shirt and up to 5.000 USD² ¹Google SoC time line
²500 USD for getting selected and another 4.500 USD for successfully participation