PEPr: Latest proposals.

PEPr Proposal [557]: PHP::Kernel

2008-05-02T11:16:41-05:00

Proposed package: PHP::Kernel

Proposer: Tsvetan Filev

PHP framework for rapid applications development. Automatic environment recognition: mobile devices; SOAP; XML-RPC; RSS

PEPr Proposal [551]: RFC::Lowercase namespace/package names in PEAR2

2008-04-13T21:27:36-05:00

Proposed package: RFC::Lowercase namespace/package names in PEAR2

Proposer: Travis Swicegood

With the introduction of namespaces we have the challenge of determining what part of a fully-qualified package name is the namespace and what is the class. This becomes a larger issue when you try to instantiate what is only a namespace.

To help with this issue, I am proposing we move to lowercase characters to signify what is part of the full name is the namespace/package name, and what part is the object.

Examples:

These examples are written assuming RFC #549 passes:

The Text_Diff package in PEAR becomes pear2::text_diff. The class Text_Diff becomes pear2::text_diff::Diff.

The Text_CAPTCHA package in PEAR becomes pear2::text_captcha. The class Text_CAPTCHA becomes pear2::text_captcha::CAPTCHA.

PEPr Proposal [550]: Web Services::Services_GeoNames

2008-04-10T02:57:03-05:00

Proposed package: Web Services::Services_GeoNames

Proposer: David Jean Louis

PEAR interface to the GeoNames web services.

The GeoNames database contains over 8,000,000 geographical names corresponding to over 6,500,000 unique features. All features are categorized into one out of nine feature classes and further subcategorized into one out of 645 feature codes. Beyond names of places in various languages, data stored include latitude, longitude, elevation, population, administrative subdivision and postal codes. All coordinates use the WGS84 system (World Geodetic System 1984).

Those data are accessible free of charge through a number of Web services and a daily database export. The Web services include direct and reverse geocoding, finding places through postal codes, finding places next to a given place, and finding Wikipedia articles about neighbouring places.

You will find more informations on the GeoNames website.

PEPr Proposal [549]: RFC::Package Naming Conventions

2008-04-06T15:32:23-05:00

Proposed package: RFC::Package Naming Conventions

Proposer: Travis Swicegood

note this is a work in progress that is merely a collection of notes at this point

This RFC calls for a change in the way package names are mapped to namespaces. It will use existing packages within the context of PEAR2 will be used throughout to show how existing code would fix into this.

Using PEAR's Text_Diff class in the Text_Diff package, in PEAR2 the class would become PEAR2::Text_Diff::Diff. Or in PHP code:




namespace PEAR2::Text_Diff;


class Diff


{


    ....

This package/namespace combination is reached via:




namespace Vendor::Package;

PEAR2 is the Vendor, the package name is Text_Diff. Within the current directory structure, this would map to include_path/PEAR2/Text_Diff/Diff.php.

Background:

PEAR packages currently do not enforce a single-directory, single-package rule. This makes it harder contain packages within a version control system through means such as Subversion's svn:externals or Git's submodules.

This proposal is aimed at making the package name map to a specific directory and that each file within that directory is considered part of its package.

Benefits:

Tracking packages within a version control system is easier as most modern vcs delineate externals along directory lines
Keeps existing package names in tact
Allows classes to be properly named by their use instead of forcing names by their location within a directory hierarchy
Helps explicitly show what is a class and what is a namespace (first two elements are always Vendor and Package Name, everything else is the class)

Drawbacks:

Changes existing, 9 year structure
Changes existing behavior of "_"

Examples:

The examples that follow are meant to be illustrative of how an existing package might fit into this new structure. These are not meant as a discussion of the benefits of one particular implement over another, but only so we are discussing familiar code.

MDB2 Example




<?php


namespace PEAR2::MDB2;


class MDB2 {


    ...





namespace PEAR2::MDB2_MySQLDriver {


class Driver {


    ...

The existing MDB2 package presents a unique case with its package and sub-package model. The current PEAR implementation of its drivers requires the naming convention "MDB2_Driver_<SomeDriver>" in order to keep all of the drivers in a central location. With the new autoload capable code, you would check for the existence of a properly named package, the MDB2_MySQLDriver (note that MySQL in this package name modifies the "Driver", and not the other way around).




<?php


// possible snippet for checking for a driver...





$driver_name = $this->getFullyQualifiedDriverName($driver);


if (!class_exists($driver_name, true)) {


    throw new UnknownDriverException($driver);


}





// etc., etc.





function getFullyQualifiedDriverName($driver) {


    if (strpos('::', $driver) === false) {


        $driver = 'PEAR2::MDB2_' . $driver . 'Driver::Driver';


    }


    return $driver;


}

This also allows for the presence of a namespace token ("::") to signify that you want to use your own driver that's not part of the PEAR2's MDB2 distribution.

Text_Diff and Text_CAPTCHA Example:




<?php


// located in include_path/PEAR2/Text_Diff/Diff.php


namespace PEAR2::Text_Diff;


class Diff {




<?php


// located in include_path/PEAR2/Text_CAPTCHA/CAPTCHA.php


namespace PEAR2::Text_CAPTCHA;


class CAPTCHA {

This demonstrates two classes that could very possibly be used in conjunction. In a normal PEAR style installation, these two files would be located in the same directory. The new method would put both of them in their own directories, allowing external developers to track versions independently.

PEPr Proposal [540]: Framework::Trigger

2008-03-09T13:51:22-05:00

Proposed package: Framework::Trigger

Proposer: Wesley Cope

Trigger 1.0 (http://openrosewood.com/files/trigger-1.0.tar.gz) is a small base framework for developing PHP5+ applications. With no complex DB structures (our db abstraction is mysqli with 3 helper functions). Following the standard (and strictly) Model View Controller (MVC) structure, Trigger is the smallest, fast, and most stable frameworks available. Utilizing PEAR setup and installation practices would allow for Trigger to have a central install of system files and make using trigger easier. Also with the plugin system, trigger can utilize PEAR packages when ever someone wants to use them

PEPr Proposal [531]: Encryption::Crypt_OpenSSL

2008-02-21T04:45:22-05:00

Proposed package: Encryption::Crypt_OpenSSL

Proposer: Pavel Saparov

This package is an openssl certificate wrapper, it contains functions such as:

* encryption/decryption with public and private keys

* creating and signing a new certificate

* retreiving infomation about the certificate

* checking if certificate corresponds to a private key

* validating usage purpose of the certificate

PEPr Proposal [515]: XML::XML_Feed

2007-11-01T11:52:58-05:00

Proposed package: XML::XML_Feed

Proposer: Michael Jackson

This package provides a base for XML feed generation classes to extend from. Already, two implementations (RSS2 and Atom) are complete. Combined with XML_Feed_Parser, this package will provide complete support for reading/writing all of the most popular types of XML feeds with PHP.

PEPr Proposal [512]: Web Services::Services_OAuth

2007-10-15T17:59:06-05:00

Proposed package: Web Services::Services_OAuth

Proposer: P�draic Brady

Implementation of the OAuth 1.0 Specification in PHP5.

PEPr Proposal [509]: HTML::webface

2007-09-23T19:19:51-05:00

Proposed package: HTML::webface

Proposer: Steven Goodwin

A method of generating HTML whereby the control and view handlers can

be abstracted, much like CSS does for layout on the client side.

WebFace comprises of four areas: view, control, authentification,

and debug. Each section contains abstractions for each part of a web page. They

may also interact, as demonstrated in the utils class.

PEPr Proposal [506]: Web Services::Docuware

2007-09-11T13:33:25-05:00

Proposed package: Web Services::Docuware

Proposer: John Mertic [Wishlist]

Interface to Docuware Internet-Server version 3.0.