design of forum applications

Very good you explanation ! Thanks mac -- ...ThE PhP_KiD. -> PEAR is much more then an abstraction layer for a database, it -> is an entire -> frame work. You cannot just take a single class from PEAR and -> use it as is, -> you'll need other parts of PEAR as well. So, let's say we are -> going to use -> MDB for our database needs. Now, our code includes a number of -> files that not -> only do the database abstraction but also PEAR style error -> handling, which is -> something we may not be using for the rest of out app. PEAR -> packages (this is -> not a bad thing per say) include a wide range of support for various -> databases, if our intended goal is to support MySQL, PostgreSQL -> and Sqlite, -> then support for oci8, fbsql, etc... is once again overhead. -> -> I'd say that PEAR is a good starting point to help you layout a -> frame work of -> your application. Perhaps, even power you app for a few early -> releases that -> will help you quickly get the 'boring' parts of the your apps engine and -> concentrate on more important things. However, once you've -> finalized the core -> of your own code and performance becomes an issue PEAR classes, in most -> cases, are something you'd want to replace with some custom code. -> -> I should point out this is not PEAR problem per say, any major -> general purpose -> class abstraction system will suffer from this regardless of the -> language. -> However, from the few packages I was genuinely interested in -> PEAR most were -> not written with performance in mind. -> -> Ilia