Hi!

Thanks for your reply Marc, I'm back with some idea for this GSoC project now .

Instead of directly talking about PHP OOP architecture, I would like to speak REST architecture style firstly. I designed and developed a RESTful web service for the last company I worked for as an intern (4th french online shoes shop), and I developed a PHP RESTful proxy.

Beyond the buzzword, it's a well-organized and extensible architecture, that fits very well with PMA. PMA is seen as a GUI that helps manage a MySQL server, but it also can be seen as a web service (disguised beneath a GUI though), transferring and building comprehensive data between the MySQL server and a end user. Plus, relational data is very prone to be REST oriented.

Why should one consider PMA as a REST oriented app ? -Client/Server architecture PMA is the client of an underlying application, MySQL, querying on behalf of the user.

- Resources Everything that comes from the server and the user work with (CRUD) can be considered as a resource : a table, a row, a user ... SQL queries change the state of theses resources, switching them into a new state.

- Uniform interface CRUD operations in DBMS are similar in nature to what HTTP methods do to resources (GET/SELECT, POST/INSERT, DELETE/DELETE, PUT/UPDATE ...).

- Resource representations Dumping data from a table is basically dumping the application state : one can select the representation he wants : CSV, LaTeX, XML, PDF ...

-URIs & Stateless Clean URIs such as /tables/myapp/users?first_name=Elvis&last_name=Presley are easily bookmark-able due to their stateless structure, and editable by experienced users via the browser's address bar for fast and simple access. Obviously it can support SQL queries and representation types like /tables/myapp?query="SELECT * FROM users WHERE first_name='Elvis' AND last_name='Presley'"&output=xml. In this example, since a URL is fetched via GET, only SELECT statement should be allowed (DESCRIBE too, but querying via URL is just a utility tool, not a full API).

There is some points on which PMA cannot be RESTful (REST oriented is enough), since it cannot handle cacheability (we need live data) and maybe some others I miss since I do not know every internal requirements.

That was my thoughts on the non-code oriented architecture topic. Now let's move on PHP ;)

Should the new architecture be PHP 5.3 compatible and leverage its new functionalities ? As you now, Zend and Sensio headed their frameworks' next major version toward PHP 5.3. What are your plans about it ? (PMA 3 being young)

Currently, PHP code is very tied to HTML code and no template solution is used. GSoC proposal says it should be easier to create new templates, so maybe we should start with a simple template engine (existing or home made) that users can learn easily. Pro and cons should considered : home made template may be faster and better integrated, but users have to learn it and documentation has to be written for example ... This separation of concerns leads to MVC architecture, which is currently the best architectural pattern for PHP web based app.

Whatever happens, an OOP structure for PMA means a big rewriting of its codebase if I'm not wrong (although some classes are already in the place) . A modular approach, with low coupling components (observer pattern, maybe DI ?) should allow code reusability and easy plugin development.

Concerning mysql drivers, what are your minds on PDO ? Actually mysql_* and mysqli_* are the two interfaces used. PDO offers some nice features (prepared statements) for an OO environment (Exceptions) and some little tiny ORM possibilities (Object hydratation-like with fetchObject).

Finally, testing could be introduced, to ensure only error free code is committed (not saying you commit code with errors :p) and that it won't break any existing functionality.

I hope my ideas is not too far away from your expectations, and that some of them will grasp your attention.

Regards, Edouard