Summary of the developer IRC session on Oct 9th. There were in the chat: IpSo__ (Mike) brr (Bjørn) canani (Ricardo) hondzik (Jan) k-fish (Karsten) k|p (Marcel) tom (Thomas) I'll try to summarize what was discussed. New developer: k|p ------------------ Most should know Marcel by now, he did the all-new settings code. Currently he is working on a new setup, to go with a new module manager. I have seen previews of this, and must say it rocks. k|p has been added to the project on sf.net and given write access to CVS, so don't be afraid of his commits. :) Removal of old wmail -------------------- We decided to remove the old wmail module. Since some people obviously use the wmail module to delete messages from the server selectively, we decided to offer it as an additional download with the next release, provided the webmail2 module has not been given this particular functionality until then. I have meanwhile removed the wmail module from CVS. SQL portability and beyond -------------------------- I have committed my work on SQL portability a while back now, so it is no real news anymore that we decided to do so. But we talked about what might be next on the database schedule. After PostgreSQL support is (mostly) finished, we'll look into adding foreign key constraints. This will give the benefit of a "integrity insurance" for those using PostgreSQL. Another thing we'll likely come up with, are guidelines to using transactions in the code. This would be of use to modules, who need to alter more than one table, depending on previous queries. Well, you all know what transactions are, no? :) ADOdb provides portable support for transactions, so this will likely be relatively easy. Testing the SQL portability was another issue. I can test MySQL and PostgreSQL, but nothing else (don't have anything else installed here, and have limited time to spend, like everyone else). So we decided to split this task. I will create an overview page, having test results and people doing the tests for various databases. Upgrading moregroupware almost constantly involves database hacking. To make this easier in the future, we decided to look at two possible solutions for this. First would be to create update-*.sql files for each release, and make setup apply those if needed. This involves manually creating those files, but greatly reduces the effort needed, compared to the task of writing some automatic database difference detection system. Another way might be the manager class of Metabase by Manuel Lemos. It should provide smoth upgrades, but all table definitions would have to be rewritten using XML. Marcel and I will be looking at this more closely when the new setup takes a stable shape. The new module manager will support the use of uninstall.sql files, to make it possible to remove all data created by a module when uninstalling this module. This is yet future, but will be there some time. Last one: we won't support databases not supported by ADOdb and/or Metabase or whatever abstraction layer we'll use. magic_quotes_gpc ---------------- This won't be a requirement any longer. We need to ensure proper quoting of all data before db insertion anyway. To do this, everyone should use the quote() method from ADOdb. It replaces the widely used qstr($var,get_magic_quotes_gpc()) call, it checks for this automatically. If inserting numerical values, always cast to (int) or (float) respectively. Dates and timestamp should always be generated using DBDate() and DBTimeStamp() from ADOdb. The check for magic_quotes_gpc has been removed from setup, so PLEASE make sure you handle your data properly! logging code ------------ k|p wrote a simple function to make logging possible. We talked about the possiblities this offers, as well as the needs of the coders. This will probably evolve to some sort of logging function, that can be called by modules at "strategically important" points, and would serve the purpose of a transaction log during regular use. It will support different log levels, so that modules can log arbitrary data, when the log level is set higher during development/debugging. A nice addon would be the possibility to view and/or purge this logs through the admin interface. performance tuning ------------------ The logging code from the previous point could help in tracking down slow parts of the code. More important seems to be some database tuning, though. Almost no indexes are used in the tables, and some of the queries at least *look* slow. I'll post a code snippet to log all SQL queries done to a file, so that everyone can look at his own SQL. explain on the MySQL command line helps with this, as well as http://www.postgresql.org/idocs/index.php?monitoring-stats.html PHP 4.0.x support ----------------- As already announced on the mailing list, support for PHP 4.0.x will has been dropped. This means we should switch to using the superglobal $_* vars as we go over the code. The decision was backed by the results of the sf.net survey (at the time of removing it, out of 36 people only 2 still used 4.0.x) and the comments on the mailing list. error_reporting(E_ALL) ---------------------- There are rumours that warnings degrade performance, and after all, making those warnings go away, enhances coding style. So we will try to purge those warnings over time. XSS exploits ------------ Those are probably a threat to all web applications. Anyway, it is only a partial solution to introduce escaping of all shown content. Some module might need the possibility to show exactly what the user inputs, so this might break things. Aside from being a lot of work (to check all the modules). Instead we decided to add the possiblity to restrict the session to the IP used when logging in. This should make session hijacking through XSS a lot harder. The code has meanwhile been added to CVS. Additionally we (again) decided to make it possible to run moregroupware with register_globals off. A lot of work towards this has already been done, but probably the same amount still lies ahead. To protect against password sniffing, we might look into introducing some challenge/response method when logging in. VNC seems to have somthing like this. This task is still available :) rights management ----------------- IpSo__ maintains the phpGACL library. After the results of the rights management poll, we decided to head for an ACL-style solution. The poll's results were not clear, but this seems to be the best solution, in terms of usability, expandability and flexibility. IpSo__ promised to look into the topic of integrating phpGACL and moregroupware, this has meanwhile led to a post to the mailing list by him. Tasks arising from this ----------------------- k-fish: 1. Set up a page showing database status. 2. Looking at metabase more closely. k|p: 1. Proposal for logging function (with IpSo__) IpSo__: 1. Research ways to integrate MGW and phpGACL Pending tasks from last session ------------------------------- All: 1. Check "own" module for non-standard SQL (important!) 2. Use the ChangeLog 3. Fix bugs... Probably a lot of interesting details are missing here, so have a look at the full log if you want the gory stuff. It is available at http://www.k-fish.de/krabutzig/mgw/devtalk-021009.html Karsten