pear:gsoc:2009

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
pear:gsoc:2009 [2009/03/10 21:26] – split channel server into two separate projects saltybeaglepear:gsoc:2009 [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 14: Line 14:
  
 ===== PHP_CodeSniffer XSS and SQL security analyzer ===== ===== PHP_CodeSniffer XSS and SQL security analyzer =====
-//Possible mentor: [[davidc@php.net|David Coallier]], [[mp@manuel-pichler.de|Manuel Pichler]]//+//Possible mentor: [[davidc@php.net|David Coallier]], [[gsoc09@pdepend.org|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 [[http://pear.php.net/PHP_CodeSniffer|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) Implement a Cross Side Scripting and SQL Injection security analyzer to find security threats in your "sniffed" code. This being a driver (extension) of [[http://pear.php.net/PHP_CodeSniffer|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)
Line 98: Line 98:
  
 ===== Extensible source code highlighter ===== ===== Extensible source code highlighter =====
-//Possible mentor: Manuel Pichler <mapi@pdepend.org>//+//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 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.
Line 121: Line 121:
 //Possible mentors: Helgi, Brett// //Possible mentors: Helgi, Brett//
  
-This will involve working on Pyrus installer which is the next generation PEAR installer. +Pyrus is a self-contained package delivery system for PHP that takes advantage of PHP's strongest features as of PHP version 5.3.
-PHP 5.3+, namespaces and all the goodies that come with PHP 5.3+
  
-This includes writing good chunks of the installer from scratches, write extensive unit tests, design APIs and still make it work with existing channels and packages. +Pyrus supports
-This will require very good understanding of PHP, XML and other technologies a like.+
  
 +  * 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:
 +
 +  - Writing unit tests for the installer in the PHPT test format
 +  - Implementing the plugin system for Pyrus
 +  - Improving the command-line interface to Pyrus
 +  - Ensuring Pyrus can manage an existing PEAR repository
 +  - Porting PECL compilation code from the PEAR Installer to Pyrus
 +  - 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
 +
 +====Deliverables====
 +===Midterm===
 +We expect a working plugin system and PECL compilation to be working on unix, as well as approximately 70% code coverage
 +
 +===Final===
 +For the final review we would expect a fully functioning installer with approximately 80% code coverage.
  
 ===== PEAR CI ===== ===== PEAR CI =====
-//Possible mentors: //+//Possible mentors: Daniel O'Connor <daniel.oconnor@gmail.com> //
  
 A proof-of-concept for a "Multi-Environment" CI instance  A proof-of-concept for a "Multi-Environment" CI instance 
Line 138: Line 186:
  
 ===Midterm=== ===Midterm===
-A working CI instance executing builds on multiple PHP versions locally+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. 
 ===Final=== ===Final===
 Backend processing pulls/receives build results from remote systems and aggregates all results for reporting Backend processing pulls/receives build results from remote systems and aggregates all results for reporting
Line 145: Line 196:
  
 PEAR can benefit by the proof instance being retained after completion. PEAR can benefit by the proof instance being retained after completion.
 +
 +
 +===== Mail_Queue2 ===== 
 +//Possible mentor: [[quipo@php.net|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.
 +
 +====Deliverables====
 +===Midterm===
 +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.
 +
 +===Final===
 +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.
 +
 +
 +
 +===== MDB3 =====
 +//Possible mentor: [[quipo@php.net|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
 +
 +====Deliverables====
 +===Midterm===
 +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.
 +
 +===Final===
 +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.
 +
 +===Optional Features===
 +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
 +
 +====Recommended Base Skills====
 +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
 +
 +
 +
pear/gsoc/2009.1236720380.txt.gz · Last modified: 2017/09/22 13:28 (external edit)