Ideas for the Google Summer of Code 2009

Here you'll find a couple of ideas for Google Summer of Code 2009 projects.

Before you submit your proposal, you are encouraged to contact the possible mentors for the project you are applying. If the project hasn't any mentor assigned or if you are submitting an off-list project, please contact one of our mailing lists to discuss the proposal before submitting it -- PEAR-DEV.

Please make sure you read the PEAR Coding Standards when applying.

Your proposal should match our Ideas Template, if you are a student and submitting an idea of your own then you should also include:

• Name and e-mail
• Availability: How many hours per week can you spend working on this? What other obligations do you have this summer?
• Bio: Who are you? What makes you the best person to work on this project? What is your experience with PHP and technologies required for this project ?

Possible mentor: David Coallier, Manuel Pichler

Implement a Cross Side Scripting and SQL Injection security analyzer to find security threats in your “sniffed” code. This being a driver (extension) of PEAR::PHP_CodeSniffer. This tool will generate reports about the threat level, list all the files/lines and variables that are affected and propose solutions to the variable. It will be very helpful to any PHP Developer and will be thoroughly used in the Q&A of PEAR and PEAR2 in general (Commercial tools and outdated tools already exist that serve the same purpose and what this tool would do is bring a new and more advanced aspect to security -- Chorizo, securityscanner, etc)

At midterm we are expecting the security scanner to be able to identify cross site scripting and sql injection vulnerabilities. The results should be as accurate as existing solutions if not better.

For the final review we'd expect the reporting functions to be fully reporting all security vulnerabilities by type and a trace of the problem ($x = $_GET['x']; function getName($a) { echo $a; } getName($x);) should trace that the vulnerability has happened because the output was not escaped properly or the input hasn't been filtered).

Possible mentors: Daniel O'Connor

http://pear.php.net/package/Spreadsheet_Excel_Writer is a popular, widely used PEAR package. It is a port of the Perl version. It has 0 test coverage, and is out of sync with the Perl version. It attracts the highest number of bugs.

Either:

• Investigate re-writing this package from the ground up, with wide test coverage.
• Investigate alternative spreadsheet authoring classes for suitability of being in PEAR (and reach out to the authors to bring it into the fold)
• Investigate and document a plan to port over bug fixes and patches.

Possible mentor: Michael Gauthier

Implement a common base class for the Amazon Web Services API. Update the Services_Amazon_S3 and Services_Amazon_SQS packages to depend on the base class. Implement a new package Services_Amazon_EC2 that covers the Amazon EC2 API. These packages will make development of cloud-computing applications easier for PHP.

At midterm, the base package should be implemented and ready as a PEAR proposal. Patches to update the existing Amazon SQS and S3 packages should be ready.

For the final review, the base package should be accepted in PEAR. The EC2 package should be fully implemented and should cover all the functionality of the EC2 API. A PEAR proposal Services_Amazon_EC2 should be ready to propose.

The applicant should:

• be able to program PHP
• understand object-oriented programming
• understand the concept of a web-service
• know what XML is

Possible mentor: David Coallier

With the new APIs being developed by Google, we need to have updated packages to make use of the performant API from the ability to draw maps to the ability to do ajax searches, get feeds, draw graphs using the visualization API, etc.

See http://code.google.com/apis/ajax/

At midterm the student is expected to have tests for each component of the APIs and be advanced in the end user documentation using the PHD documentation tool

The student should be done with the base class and the API child classes for Maps, Ajax Search, Ajax Feed, Visualization API, Language API and Libraries APIs. Each classes should be fully tested and documented and working.

Possible mentor: Brett Bieber

An official channel server within the PEAR repository would be a welcomed addition and would advance PEAR's installation and distribution methods. The current PEAR channel servers are hosted on external servers, and need to be re-worked to a polished PEAR package that is up to PEAR's standards.

At midterm the student is expected to have PEAR channel server code up to PEAR coding standards, and ideas on improving the package so it will meet PEAR's standards.

The student should have the Channel Server api complete, fully unit tested, and proposed to PEAR's proposal process. A command line utility for releasing packages which creates the xml files for a PEAR channel.

Possible mentor: Brett Bieber

The current PEAR channel servers are hosted on external servers, and need to be re-worked to a polished PEAR package that is up to PEAR's standards. This will be an official channel that will function as the basis for the PEAR2 website, and possibly PEAR, PECL, and doc.php.net PEAR Channel websites.

At midterm the student is expected to have a public frontend for viewing a channel server, which utilizes the code within Pyrus and the Command Line PEAR Channel Server for server file creation.

The student should have the web site feature complete, with administrative pages for releasing packages and managing user accounts, as well as a public frontend for viewing packages.

Possible mentor: Manuel Pichler gsoc09@pdepend.org

The basic scope of this component is highlighting source code of various programming languages. It is limited to common text based one dimensional programming languages, not designed to also work for esoteric languages. Several existing syntax highlighters already can directly generate HTML syntax highlights, but this is not feasible for all applications.

The approach basically works by using common EBNFs for the definition of the syntax of the scanned programming language, simplification of the resulting AST using sorts and then visiting the simplified AST into different output formats, like HTML or a line based token stream. A more detailed requirements document can be found here: http://k023.de/accent_requirements.txt - the requirements might be required to be adapted to PEAR rules.

The scanning of at least one simple EBNF and the parsing of source code files should already be done. The parsing might be implemented using a parser generator or a generic parser.

The Syntaxhighlighting should work for at least some common languages, like PHP, HTML and ECMAScript. HTML and Tokenstreams should be implemented as output formats. Since parsing can be error prone, the component should already have a high code and path coverage.

Optionally rules for language switches inside of single files, and switches of the parser can be implemented.

Possible mentors: Helgi, Brett

Pyrus is a self-contained package delivery system for PHP that takes advantage of PHP's strongest features as of PHP version 5.3.

Pyrus supports

• Robust, remote dependency validation and download
• Creation of phar/zip/tar packages in conjunction with the Pyrus_Developer package
• Installation of local or remote packages and abstract package installation (as in “install the beta version of this package”)
• Redundant registries, allowing re-building corrupted installs
• Registries in Sqlite, Xml, and Serialized PHP format
• managing PEAR installations
• Packages that can work with or without installation to support try-before-you-buy or bundling packages in other projects
• Full asymmetric signed packages using OpenSSL (natively supported through the phar extension)
• No need to install Pyrus, run directly from the downloaded phar archive.
• Customizability through extensions to Pyrus

This is a major leap of functionality over the PEAR Installer, and will be a major component of the PHP Language when completed, as the PEAR installer was for earlier versions of PHP.

To develop Pyrus, you need to have the ability to work with the following technologies on a very high level:

• Subversion source repository use
• XML (including proficiency in XMLReader/XMLWriter/SimpleXML extensions)
• PHP 5 Object-Oriented getters/setters (get/set)
• PHP 5 Object-Oriented ArrayAccess interface
• PHP 5 Iterator interface
• PHP 5 SPL iterators
• PHP 5 exceptions and exception handling
• SQL and Sqlite database, in order to maintain Sqlite3 registry

You also need a basic understanding of:

• PHP Namespaces (new in PHP 5.3)
• PHP closures (new in PHP 5.3)
• PHPT testing format
• Testing methodologies (code coverage/testing behavior/designing code to be testable)
• PEAR packages and the PEAR Installer
• Basic compilation of PECL extensions

Architecturally, you will be expected to assist in the following processes:

1. Writing unit tests for the installer in the PHPT test format
2. Implementing the plugin system for Pyrus
3. Improving the command-line interface to Pyrus
4. Ensuring Pyrus can manage an existing PEAR repository
5. Porting PECL compilation code from the PEAR Installer to Pyrus
6. General bugfixing/small feature implementation as specified by the Pyrus roadmap

As of the proposal, Pyrus is at approximately 50% code coverage, and it will be much higher by the time GSoC begins

We expect a working plugin system and PECL compilation to be working on unix, as well as approximately 70% code coverage

For the final review we would expect a fully functioning installer with approximately 80% code coverage.

Possible mentors: Daniel O'Connor daniel.oconnor@gmail.com

A proof-of-concept for a “Multi-Environment” CI instance - runs builds against multiple PHP versions across multiple OSs (via VMs if necessary) - aggregates build results from all sources, even remote ones

A working CI instance executing builds on multiple PHP versions locally.

Solid and easy to understand documentation on setting this up with a minimum of fuss.

Backend processing pulls/receives build results from remote systems and aggregates all results for reporting

The additional code/scripts/etc developed to complete this proof-of-concept could be incorporated into CruiseControl, phpUnderControl, etc, as patches provided to those projects.

PEAR can benefit by the proof instance being retained after completion.

Possible mentor: Lorenzo Alberton

The current Mail_Queue package is suffering from a lot of shortcomings that could only be overcome by a full rewrite.

The purpose of a mail queuing system is to store the outgoing emails in a persistent location (such as a database) before they are sent, and provide convenience methods to send the emails in smaller chunks, via a cron job / scheduled task, to cope with the available resources (SMTP, MTA, network, CPU) and spread the load over a longer period of time.

We would expect a basic mail queuing system capable of handling multiple recipients (Cc/Bcc), db locking to avoid concurrent access and multiple deliveries, proper error handling (mostly non-blocking, since the emails are sent in batches) and logging. The buffer/queue management should be fault-tolerant and efficient.

For the final review we would expect a fully functioning package with support priority levels, persistent connections, ability to delay a mail in case of smtp sending errors (by checking the returned SMTP error, for instance), and logging/reporting features.

Possible mentor: Lorenzo Alberton

Rewrite the MDB2 db abstraction layer with PDO-based drivers, making full use of SPL iterators, cursor support, and getting rid of the PHP4 legacy.

PDO only offers API abstraction, but is not a database abstraction layer. A DBAL takes care of abstracting data types and some features at the language level (LIMIT, SEQUENCEs, Subqueries, ...). http://en.wikipedia.org/wiki/Database_abstraction_layer

We would expect a full implementation of at least two db drivers, ideally already featuring a draft implementation of a Manager and Reverse module. A fairly complete test suite should be written as soon as possible to keep track of the state of each driver.

For the final review we would expect at least three database drivers with support for DDL and DML statements, SQLSTATE codes, emulation of common functions and introspection. If the underlying DBMS supports it, the driver should also be capable of handling multiple resultset. A complete test suite, ideally including a mock driver, should demonstrate the support of each feature in each driver.

If the quality of the work done is up to the expectations, and the time allows for it, it would be nice to have some extra features:

• EXPLAIN abstraction
• import/export in CSV format
• database/table/row LOCKs
• support for CHECK constraints

The applicant should:

• have a good PHP5 knowledge (PDO, SPL)
• have a very good understanding of object-oriented programming
• have experience with at least two/three different DBMS