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
Next revisionBoth sides next revision
pear:gsoc:2009 [2009/03/11 09:26] – used gsoc only email davidcpear:gsoc:2009 [2009/03/12 14:50] quipo
Line 148: 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, 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.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1