Differences

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

--- pear:gsoc:2009 [2009/03/10 21:07] – add PEAR CI idea ashnazg
+++ pear:gsoc:2009 [2009/03/12 14:50] – quipo
@@ Line 14: / Line 14: @@
 ===== 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)
@@ Line 70: / Line 70: @@
 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.
-===== Official PEAR Channel Server =====
+===== Command Line PEAR Channel Server =====
 //Possible mentor: [[saltybeagle@php.net|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.
+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.
 ====Deliverables====
 ===Midterm===
-At midterm the student is expected to have the existing PEAR channel server code up to PEAR coding standards, and ideas on improving the package so it will meet 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.
 ===Final===
-The student should have the Channel Server api complete, fully unit tested, and proposed to PEAR's proposal process.
+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.
+===== Web Frontend For A PEAR Channel Server =====
+//Possible mentor: [[saltybeagle@php.net|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.
+====Deliverables====
+===Midterm===
+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.
+===Final===
+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.
 ===== 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.
@@ Line 114: / Line 129: @@
 ===== PEAR CI =====
-//Possible mentors: //
+//Possible mentors: Daniel O'Connor <daniel.oconnor@gmail.com> //
 A proof-of-concept for a "Multi-Environment" CI instance
@@ Line 123: / Line 138: @@
 ===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===
 Backend processing pulls/receives build results from remote systems and aggregates all results for reporting
@@ Line 130: / Line 148: @@
 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

Differences

Page Tools