Re: Merging PHPLIB into PEAR

Chuck Hagenbuch wrote: > > Quoting Ulf Wendel <ulf.wendel@phpdoc.de>: > > > PEAR lacks solutions for sessions, permissions, authentification, > > templates... > > I'll agree on templates. I don't see what kind of support PEAR _needs_ for > sessions - what does the phplib session class do that the php4 native functions > don't do? PEAR does not provide any classes to extend the PHP 4 session handling to save session data on other media but the filesystem. This is poor. PHPLib is a prototype implementation of sessions. The CT_* layer allows you to save the session data in a DB, ... Where's the PEAR class that allows you to save session data at least to a MySQL database? > I'm of the (certainly arguable) opinion that authentication and permission > classes don't belong in PEAR itself. See below for more. Hmm. > > I like most of PEAR, but beside the DB abstraction there're no classes of > > real importance. > > That's a rather arbitrary statement, isn't it? For one thing, it ignores > PHPDoc, though whether or not that should be in PEAR is another matter; for > another, there are plenty of classes which if you had a need for them might be > very important. PHPDoc is checked in to the PEAR repository but on the long run the classes and the applications have to be seperated and I was referring to the PEAR classes. > > Let's look forward how we can add the PHPLib to PEAR to build an > > "application framework" (in the sense as PHPLib is one) that makes PHP 4 > > even more powerful. > > I don't think that this is necessarily a good idea. An application framework > dictates a specific philosophy of application design on the people writing Stop. Don't build a simple CPAN copy. None of the "enterprise" users needs lots of little, nice classes that do not adress key issues in the webapplication development: db, session, perm, auth, xml, xslt, template, some html widget classes. The bad thing on Java or Perl is that you can't say you know the language unless you know lots of library code. Let's concentrate to build an integrated core system. Such a system determines the success of PEAR not amount of classes. The "application framework" would be loosely tight together. As with PHPLib you can use every class on it's own (beside some few dependencies). You don't have to use perm and auth, but you may use it and be able to write full-fledged applications just by using the given solution. You don't have to rebuild this code every time. If you don't like the perm, auth or whatever implementation it's still a good starting point for your own implementation and you'll be able to learn from the prototyle. > applications. Things like permissions and authentication, no matter how > generically written, dictate some model of permissions, some model of That's not really of importance. IT managers considering to use PHP should always hear "Use PHP it comes with PEAR, that's a cool framework for developing webapplications, it's more than a source collection like CPAN is.". Ulf