Re: PEAR usage

Dan Allen said: > PEAR needs to be able to work without having the libraries in the > include path (since it is not possible to modify this setting at > runtime). The reason for this is that many webhosts have not yet > become acquainted with PEAR and therefore do not have it installed. > Here is my solution...the PEAR installer should run though the > libraries and somehow resolve the paths, or perhaps we should think > of a way for the libraries to be able to call themselves without > requiring PEAR to be in the include path... > > People need to be able to run PEAR libaries without them being in > the system include path...if that is done, then PEAR can be > embedded in applications. Let me know what you think. Hi Dan, in principle, you´re right - one of the reasons why PEAR has not been widely adopted so far is that it´s not available by default at many providers. Application developers, on the other hand, might think that the need for having those libraries in the include_path doesn´t fit into their concept. Another fear may be that sometimes from one version to another, the API of a specific class may change, which might break some applications. Having PEAR in a generic path used by many applications (where probably one needs a specific class in version 1 and another app needs the same class in version 2 => BANG!) can be tricky. You specifically mentioned phpBB as one of the applications rejecting the use of PEAR. An application as popular as that tends to have a huge installation base also on virtual webservers at very, very cheap providers. Those providers don´t neccessarily allow their users to use Telnet or SSH, so they can´t use the PEAR installer. Some of those providers won´t even allow configuration overrides with .htaccess other than basic authentication. So you have absolutely no possibility to set your own include_path except for ini_set, which is unlikely to be supported by many applications. I don´t know a really good solution for this problem. One thing I can think of is defining a specific global variable used by all PEAR classes that contains the path to your desired PEAR version, something like $__PEAR_INCLUDE_PATH ... Another solution might be that you can put a configuration file at a specific place within $DOCUMENT_ROOT, that must be included before any other PEAR class. If would read some XML config file belonging to your applicaiton in the same directory and makes the appropriate ini_set call. Something like this: // My application is called CoolApplication, define that in a constant define("PEAR_CURRENT_APPLICATION", "CoolApplication"); // Include the configuration script that now reads an XML file called // CoolApplication.xml and makes the ini_set call, setting the // include_path include_once($DOCUMENT_ROOT."/PEAR_Config/PEAR_Config.php"); // Now include classes as usual... include_once("DB.php"); ...I guess both methods are not very elegant, but as I said I can´t think of a really good solution for this right now. Regards, Markus -- *21st Media* | Consulting, Konzeption, Produktion für die Bereiche: Markus Wolff | Internet, Intranet, eCommerce, Content Management, Hamburg,Germany | Softwareentwicklung, 3D-Animation, Videostreaming http://21st.de | Tel. [+49](0)40/6887949-0, Fax: [+49](0)40/6887949-1