cvs: pear / manifest.html

ssb Thu May 9 17:11:34 2002 EDT Added files: /pear manifest.html Log: * Behold, The PEAR Manifest! Index: pear/manifest.html +++ pear/manifest.html <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="GENERATOR" content="Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686) [Netscape]"> </head> <body> <h1> The PEAR Manifest</h1> Stig S&aelig;ther Bakken, january 2002 <h1> * What is PEAR?</h1> PEAR is short for "PHP Extension and Application Repository" and is pronounced just like the fruit.&nbsp; PEAR aims to provide: <ul> <li> A structured library of open-sourced code for PHP users</li> <li> A system for code distribution and package maintenance</li> <li> A standard style for code written in PHP</li> <li> The PHP Foundation Classes (PFC), see more below</li> <li> The PHP Extension Code Library (PECL), see more below</li> <li> A web site and mailing lists supporting the PEAR community</li> </ul> <h2> ** Frequently Asked Questions</h2> This section is for clearing up common misunderstandings. <ul> <li> PEAR is not a single application framework.&nbsp; PEAR can however host frameworks and let users maintain them with PEAR tools, and frameworks may take advantage of existing PEAR components.</li> </ul> <h2> ** Structured Library of PHP Code</h2> The code in PEAR is partitioned in "packages".&nbsp; Each package is a separate project with its own development team, version number, release cycle, documentation and a defined relation to other packages (including dependencies).&nbsp; Packages are distributed as gzipped tar files with a description file inside, and installed on your local system using the PEAR installer. <p>PEAR defines a package tree, where each "node" in the tree is represented by a part of the package name.&nbsp; The nodes are organized by simple descriptive topics, and each part is separated by an underscore.&nbsp; Examples of package names are "MP3_Id", "Archive_Tar" and "HTTP_Post". <p>Packages may relate to eachother through explicit dependencies, but there is no automatic relation between for example a package and its "parent" in the package tree (for example, "HTTP_Post" is by default independent of "HTTP"). <p>A few top-level nodes in the package tree called "sub-repositories" have special functions, currently these are "PECL", "Gtk" and "App".&nbsp; For each of these, different rules apply, see more in the description of each sub-repository below. <p>A style guide, the PEAR Coding Standards (short PCS), exists to ease collaboration between PEAR developers, to help quality and portability, and to help PEAR contributors in providing consistent-looking-and-feeling APIs.&nbsp; For packages in the PFC, this standard applies strictly, while more relaxed (advisory rather than mandatory) for non-PFC packages. <h2> ** Code Distribution and Package Maintenance</h2> All PEAR packages are registered in and uploaded to a central database available at pear.php.net.&nbsp; Open-sourced third-party packages may also be registered and uploaded.&nbsp; Closed-source packages may be installed by the PEAR installer, but the PEAR database is for open-source code. <p>Pear.php.net will provide both a human-friendly (HTML) and machine-friendly (currently XML-RPC) interface to the PEAR database.&nbsp; Package downloads are done with plain HTTP.&nbsp; Other functions provided by pear.php.net web site are: <ul> <li> user account management</li> <li> package management</li> <li> release management</li> </ul> Packages are distributed as a tar files that are usually gzipped. They include an XML index/description file inside. The description file contains some information about the package, a list of files and their roles, and dependencies. <h2> ** The PHP Foundation Classes (PFC)</h2> The PHP Foundation Classes is a subset of PEAR that focuses on quality, generality, interoperability and compatibility.&nbsp; If PHP is going to continue bundling PEAR packages beyond the installer, it will bundle the PFC. <p>Focus on quality means that no packages or releases or less than "stable" quality are accepted in the PFC. <p>Generality means that packages should not be more than reasonably specific to any type of environment (such as an output format like HTML, an operating system, a web server or SAPI backend etc). <p>Interoperable packages work well with other packages, have stable, standardized APIs, prefer other well-established (and also interoperable) components and also work well in different environments (PHP version, SAPI backend, operating system etc.) <p>Compatibility is not just about supporting the same syntax and semantics as earlier versions, it is also about planning ahead when writing the code.&nbsp; Designing code so it would be easy, or at least possible, to add features that are likely to appear later, gives code that is also "forward-compatible". <p>This document does not specify which packages will be part of the PFC. <h2> ** The PHP Extension Code Library (PECL)</h2> PECL (pronounced "pickle") is a sub-repository of PEAR for C extensions ala those distributed with PHP 4, in fact, PECL was created to have somewhere to move extensions when they are no longer bundled with PHP.&nbsp; Extensions in PECL follow PHP's coding standards rather than PEAR's, but they are distributed and installed as PEAR packages. </body> </html>