pear:gsoc:2009
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
pear:gsoc:2009 [2009/03/10 21:26] – split channel server into two separate projects saltybeagle | pear:gsoc:2009 [2009/03/12 14:50] – quipo | ||
---|---|---|---|
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 " | Implement a Cross Side Scripting and SQL Injection security analyzer to find security threats in your " | ||
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 129: | Line 129: | ||
===== PEAR CI ===== | ===== PEAR CI ===== | ||
- | //Possible mentors: // | + | //Possible mentors: |
A proof-of-concept for a " | A proof-of-concept for a " | ||
Line 138: | Line 138: | ||
===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/ | Backend processing pulls/ | ||
Line 145: | Line 148: | ||
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, | ||
+ | The buffer/ | ||
+ | |||
+ | ===Final=== | ||
+ | For the final review we would expect a fully functioning package with support priority levels, persistent connections, | ||
+ | |||
+ | |||
+ | |||
+ | ===== 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, | ||
+ | A DBAL takes care of abstracting data types and some features at the language level (LIMIT, SEQUENCEs, Subqueries, ...). | ||
+ | http:// | ||
+ | |||
+ | ====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, | ||
+ | * EXPLAIN abstraction | ||
+ | * import/ | ||
+ | * database/ | ||
+ | * 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.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1