Re: PHPlib PEAR

> >> We aren't really re-inventing the wheel here. We are analyzing the wheel > > Great, fine and perfect. > I think, for example, an "OO wrapper" for session_set_save_handler(), > is a great thing and there is an phplib approach for that issue. Cool, so bring it into PEAR. Keep in mind though that I shouldn't have to commit to using the PHPLIB framework in order to use components of PHPLIB. Having the option to do so is fine, but I want to be able to go into PEAR and find myself a small targeted component that solves the problem I am currently facing without being forced to completely rewrite and rethink how I have built my application. With a bit of thought I think PEAR can provide both small standalone components and also provide larger frameworks. I envision something like: DB/ PHPLIB/ Auth/ BinaryCloud/ File/ Midgard/ Image/ HTML/ HTTP/ Console/ Crypt/ Math/ Net/ XML/ Schedule/ Log/ Mail/ That is, standalone components separated out from frameworks. If there are components that are part of PHPLIB that really can't be used standalone for some reason, leave them in the PHPLIB directory. But if there are parts that can be simplified and split out into a standalone component completely separate from PHPLIB then that should be done. I don't agree with the view that PHPLIB is the one true application framework that PEAR should become. Nor do I believe that any such one true app framework exists. I personally am not keen on application frameworks. Takes me longer to understand the framework than to just write the code that solves my problem. That doesn't mean I wouldn't use a framework once I understood it. For large projects it is pretty much a requirement. -Rasmus