PEPr: Latest proposals containing config

PEPr Proposal [638]: HTTP::HTTP_OAuth2

2010-06-16T23:02:16-05:00

Proposed package: HTTP::HTTP_OAuth2

Proposer: Laurence Miao

PEPr Proposal [614]: HTTP::HTTP_Browser

2009-09-27T00:23:34-05:00

Proposed package: HTTP::HTTP_Browser

Proposer: Dylan Doxey

PEPr Proposal [709]: HTTP::HTTP_Request

2015-01-09T15:54:08-05:00

Proposed package: HTTP::HTTP_Request

Proposer: Gonzalo Chumillas

A library for sending HTTP requests from the server side. For example:



<?php



// in this case we use a configuration object

$config = new HttpRequestConfig();

$config->setOption("follow_location", true);

$config->setOption("user_agent", "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36");

$config->setContentTypeOption("charset", "iso-8859-1");



// sends a POST request to mysite.com and attaches some files

$req = new HttpRequestPost($config);

$req->setParam("action", "upload-image");

$req->setFormParam("image", new HttpRequestFormFile("/path/to/image.jpg"));

echo $req->send("http://www.mysite.com");

?>

PEPr Proposal [687]: Database::DB_DataObject_FormBuilder_Frontend

2012-12-20T11:54:13-05:00

Proposed package: Database::DB_DataObject_FormBuilder_Frontend

Proposer: Mads Lie Jensen

Package to build frontends for database editing. The most basic use requires very little code, most is done in a config-file written in xml.

It displays list of tables that can be edited, lists the contents of the tables and forms for editing/adding/deleting records from these tables.

Database access is done using DB_DataObjects, forms for editing is made using DB_DataObject_FormBuilder and the lists of tables or table-contents with Structures_DataGrid. This makes the behavior and output very flexible. But if not flexible enough, the package can be easily expanded using plugins and different forms of callback-methods.

Code can be found on Github

PEPr Proposal [626]: HTML::HTML_Template

2010-02-01T00:08:01-05:00

Proposed package: HTML::HTML_Template

Proposer: Jaco

PEPr Proposal [605]: Mail::Mail_CheckUser

2009-07-15T14:35:10-05:00

Proposed package: Mail::Mail_CheckUser

Proposer: Takayuki Miyauchi

PEPr Proposal [585]: RFC::Unit tests, new packages, good practice

2008-12-30T03:46:02-05:00

Proposed package: RFC::Unit tests, new packages, good practice

Proposer: Daniel O'Connor

PEPr Proposal [273]: Console::Console_Wizard

2005-07-08T08:39:08-05:00

Proposed package: Console::Console_Wizard

Proposer: Clay Loveless

The Console_Wizard package provides methods for creating, validating and processing multi-screen interactive console applications.

Similar in many ways to HTML_QuickForm and HTML_QuickForm_Controller, Console_Wizard's features include:

Intuitive handling of multiple-choice questions, yes/no questions and user-input questions.

QuickForm-style validation rules for responses.

Customizable application headers, footers, prompts, and default answers.

Configurable per-response callback function/method and "goto" settings.

Wizard-wide process callback handling.

Automatic generation of multiple-choice indexes for multiple-choice questions.

Easily extendable filters and rules.

For those aiming to maximize their financial gains, pure profit point offers a comprehensive toolkit tailored for modern investors.

PEPr Proposal [650]: Web Services::Services_Twitter_Uploader

2010-12-20T12:30:03-05:00

Proposed package: Web Services::Services_Twitter_Uploader

Proposer: takumi taka

simple & easy post OAuth Echo Upload services.

support upload service

http://img.ly/api/docs

http://twitgoo.com/a/help

http://dev.twitpic.com/

http://code.google.com/p/imageshackapi/

http://p.twipple.jp/wiki/Main_Page

http://plixi.com/api

http://apidocs.posterous.com/pages/twitter

http://developers.mobypicture.com/documentation/

sample code

https://gist.github.com/748086



<?php



require_once "Services/Twitter/Uploader.php";

 

$oauth = new HTTP_OAuth_Consumer('APP KEY', 'APP SECRET', 'TOKEN', 'SECRET');

 

$uploader = Services_Twitter_Uploader::factory('yfrog', $oauth);

//twitpic require api key http://dev.twitpic.com/apps/new

//$uploader = Services_Twitter_Uploader::factory('twitpic', $this->oauth, 'apiKey');

//proxy

//$req = new HTTP_Request2();

//$req->setConfig(array( 'proxy_host' => 'HOST', 'proxy_port' => 'PORT'));

//$uploader = Services_Twitter_Uploader::factory('yfrog', $oauth, null, $req);

 

try {

    $url = $uploader->upload('/path/to/upload.jpg', 'from Services_OAuthUploader');

    var_dump($url); // upload URL

} catch(Twitter_Uploader_Exception $e) {

    var_dump($e);

}

?>

PEPr Proposal [645]: Configuration::Config_Lite

2010-08-31T02:15:49-05:00

Proposed package: Configuration::Config_Lite

Proposer: Patrick Engel

a simple, lightweight and fast class for ini style configuration files, with the native PHP function "parse_ini_file" under the hood.

Config_Lite is inspired by Pythons ConfigParser.

A "Config_Lite" file consists of global options as "name = value" entries on top and sections, "[section]", followed by "name = value" entries.

Examples

The Config_Lite Pear Package:

https://github.com/pce/config_lite

A Configuration File: `test.ini'



public_key_file =  "~/.ssh/id_rsa.pub"

debug = yes



[general]

lang = "en"



[db]

user = "dionysis"

password = "c2oiVnY!f8sf"

Read Configuration file:



<?php





require_once 'Config/Lite.php';



$config = new Config_Lite('test.ini');



echo $config->get('db', 'user'); // dionysis

echo $config->get(null, 'public_key_file'); // ~/.ssh/id_rsa.pub



if (true === $config->getBool(null, 'debug', true)) {

        echo $config;

}



// read with ArrayAccess

echo $config['db']['password']; // c2oiVnY!f8sf

?>

Save Configuration file:



<?php



$config->set('db', 'user', 'JohnDoe')

        ->set('db', 'password', 'd0g1tcVs$HgIn1');



// set with ArrayAccess

$config['public_key_file'] = '~/.ssh/id_rsa.pub';

$config['general'] = array('lang' => 'de');



// save object to file

$config->save();

?>

Create configuration file:



<?php





$config = new Config_Lite('test.ini');

$config->set('db', 'user', 'JohnDoe')

        ->set('db', 'password', 'd0g1tcVs$HgIn1');



// set global bool 'debug'

$config->set(null, 'debug', false);



// save object to file

$config->save();

?>

Alternative file creation with write:



<?php





$config = new Config_Lite();

$config->write('test.ini', array(

                        'public_key_file' =>  "~/.ssh/id_rsa.pub",

                        'general' => array(

                                'lang' => 'fr'

                        ),

                        'db' => array(

                                'user' => 'dionysis',

                                'password' => 'd0g1tcVs$HgIn1'

                        )

                );

?>

global Configuration options (without sections) :



<?php



$config->set(null, 'private_key_file', '~/.ssh/id_rsa');

// set with arrayaccess

$config['public_key_file'] = '~/.ssh/id_rsa.pub';



$config->sync();



echo $config->get(null, 'public_key_file');

// get with arrayaccess

echo $config['private_key_file'];

?>

Notes & Limitations

Use getString and setString to save and read Strings with double and single-quotes.

Use getBool if you need a real bool type, eg. for strict equality comparision.

The methods `set' and `get' keep values untouched, but the write method normalize "bool" values to a human readable representation, doublequotes strings and numeric values without any quotes.

File locking is not part of this Class.

No support of comments and multiline strings, because reading with "parse_ini_file" does not support it.

If you want to save a regex, i'd recommend to use "get" with base64_decode and "set" with base64_encode.

Save regex (as global option) base64 encoded :



<?php





$config = new Config_Lite('regex-test.ini');



$regex = '/Hello \"(.*?)\"/';

$config->set(null, 'regex', base64_encode($regex));

// save object, here sync to read it back, just to test

$config->sync();

// in 'regex-test.ini': regex = "L0hlbGxvIFwiKC4qPylcIi8="

$regex = base64_decode($config->get(null, 'regex'));

if (preg_match($regex, 'Hello "World"!')) {

    printf("matched. regex:%s", $regex);

} else {

    printf("no match found. regex:%s", $regex);

}

?>

Game MENANG123 merupakan game gacor terpercaya.

PEPr Proposal [623]: Images::Image_QRCode

2009-12-13T19:30:53-05:00

Proposed package: Images::Image_QRCode

Proposer: Rich Sage

PEPr Proposal [601]: PEAR::PEAR_TestListener

2009-06-09T02:19:05-05:00

Proposed package: PEAR::PEAR_TestListener

Proposer: Laurent Laville

PEPr Proposal [578]: Logging::Log_FirePHP

2008-10-11T09:57:41-05:00

Proposed package: Logging::Log_FirePHP

Proposer: Laurent Laville

PEPr Proposal [536]: Streams::Stream_Iterate

2008-03-05T19:04:19-05:00

Proposed package: Streams::Stream_Iterate

Proposer: Philippe Jausions

Overview

Here's a little class to allow accessing a traversable variable (array, Iterator, etc...) as a stream using callbacks. The variable is transversed and each key/value is passed to the callback(s) to be transformed into a string to be piped into the stream. The stream is read forward-only, and has an undetermined length.

I first developed this class to use with MDB2_Iterator and HTTP_Download (note that HTTP_Download needs the patch of bug #13125 to handle undetermined content size.)

With PHP 5.3+ there will be stream context support for copy(). That will allow to very easily dump data to file (see example)

Code Sample



<?php



require_once 'Stream/Iterate.php';



// Register class as "foreach" protocol

stream_wrapper_register('foreach', 'Stream_Iterate');



// Some data we can iterate over with foreach (array, Traversable, etc...)

// We'll assume $db MDB2 connection is configured somewhere else

$data = new MDB2_Iterate($db->query('SELECT * FROM sometable'));



// Callback to convert the data into a string that will be

// piped into the stream (any valid callback will do)

$callback = create_function('$key, $value, $iteration', 'return $key."=".implode(',', $value)."\r\n";');



// Create the context for the stream

$context = stream_context_create(array('foreach' => array('subject' => $data, 'toString' => $callback)));



$fp = fopen('foreach://subject', 'r', false, $context);



HTTP_Download::staticSend(array('resource' => $fp));



?>

URL Examples

(assuming "foreach" is the name of the registered protocol):

"key" and "value" specify which of the key and value should be passed to the callback and in which order.

foreach://key:value@subject

foreach://value:key@subject

foreach://key@subject

foreach://value@subject

foreach://subject

If not specified, "key:value" will be assumed. So protocol://subject

is equivalent to protocol://key:value@subject

Callback / Formatter in URL

To each of the URL examples above you can append a query string made up of. These substitute for the context options, possibly leading to more self-explanatory URLs.

toString=function_name

toString=class::method

formatter=class_name (class_name must implements Stream_Iterate_FormatterInterface)

Example: foreach://value@subject?toString=serialize

TODO

* Documentation / more examples (besides the test suite)

darknet market links

PEPr Proposal [528]: File System::File_Mogile

2008-01-30T00:16:25-05:00

Proposed package: File System::File_Mogile

Proposer: Steve Williams

PEPr Proposal [457]: GUI::XML_SWFGauge

2006-10-25T22:26:14-05:00

Proposed package: GUI::XML_SWFGauge

Proposer: Jack Herrington

PEPr Proposal [441]: PHP::PHP_Annotation

2006-08-28T11:08:08-05:00

Proposed package: PHP::PHP_Annotation

Proposer: Kouichi Sakamoto

PHP_Annotation, Attribute Extension is supported to Class,Function,Method and Property. And, the DI library is supported.

-- Function list --

1. Get Annotation Object

- PHP_Annotation::parse(string $class_name);

- PHP_Annotation::parse(string $function_name);

- PHP_Annotation::parseFunction(string $function_name);

- PHP_Annotation::parseMethod(string $class_name, string $method_name);

- PHP_Annotation::parseProperty(string $class_name, string $property_name);

- PHP_Annotation::parse(Reflector $ref);

* Parse Comment by using getDocComment() of Reflector.

2. Getting processing result useing by Annotation Object.

- PHP_Annotation::exec(PHP_Annotation_Factory $factory=null); support java.lang.annotation format.

- PHP_Annotation::exec[Command Name](); ref:PHP_Annotation::__call()

- PHP_Annotation::exec_[Command Full Name](); //ref:PHP_Annotation::__call()

* Support PhpDocumentor and java.lang.annotation format.

Because used Command design pattern, An easily original format can be built in.

3.Use DI library

- PHP_Annotation_ContainerFactory::singleton()

- PHP_Annotation_ContainerFactory::setContainerConfig( PHP_Annotation_ContainerConfig $config=null)

- PHP_Annotation_ContainerFactory::getComponent( string $name )

* Support annotation: @construct, @instance, @property

* Exsample: sample6.php

.

Which sites accept Inclave and how it works, read here.

PEPr Proposal [435]: Web Services::Services_YouTube

2006-08-07T15:29:47-05:00

Proposed package: Web Services::Services_YouTube

Proposer: Shin Ohno

PEPr Proposal [431]: Text::Text_Bayes

2006-07-28T16:55:36-05:00

Proposed package: Text::Text_Bayes

Proposer: Andreas Ahlenstorf

PEPr Proposal [381]: PEAR::PEAR_PackageFileManager_Frontend

2006-03-27T19:18:58-05:00

Proposed package: PEAR::PEAR_PackageFileManager_Frontend

Proposer: Laurent Laville

PEPr Proposal [361]: XML::Query2XML

2006-02-28T14:10:31-05:00

Proposed package: XML::Query2XML

Proposer: Lukas Feiler

PEPr Proposal [350]: System::System_Folders

2006-02-01T10:49:15-05:00

Proposed package: System::System_Folders

Proposer: Christian Weiske

PEPr Proposal [346]: Gtk2 Components::Gtk2_PHPConfig

2006-01-22T16:13:45-05:00

Proposed package: Gtk2 Components::Gtk2_PHPConfig

Proposer: Anant Narayanan

PEPr Proposal [267]: Tools and Utilities::CodeGen_PECL

2005-07-03T09:40:57-05:00

Proposed package: Tools and Utilities::CodeGen_PECL

Proposer: Hartmut Holzgraefe

PEPr Proposal [248]: Networking::Net_Wifi

2005-05-07T18:47:37-05:00

Proposed package: Networking::Net_Wifi

Proposer: Christian Weiske

PEPr Proposal [171]: Networking::Monitor

2004-11-02T21:24:32-05:00

Proposed package: Networking::Monitor

Proposer: Robert Peake

PEPr Proposal [132]: RFC::Error Handling Guidelines for PHP5 packages

2004-08-09T14:50:00-05:00

Proposed package: RFC::Error Handling Guidelines for PHP5 packages

Proposer: Sérgio Carvalho

Error Handling Guidelines for PHP5 packages submitted to PEAR

Summary

This document defines guidelines for error handling within PEAR, for PHP5 packages. It was written to cope with Exceptions, introduced in Zend Engine 2 as the error handling mechanism. The final objective is to integrate the document text into the PEAR Coding Guidelines.

Audience

This document is targeted at PHP developers writing packages for submission into the PEAR repository. As any coding guidelines, it is useful to developers using PHP in other environments. The requirements for reading this text are only familiarity with PHP as a programming language, as well as familiarity with the mechanism of Exceptions as an error handling mechanism.

For those PHP developers unfamiliar with Exceptions, the wiki page from which this document was extracted provides a good introduction, as well as pointers to other references.

Definition of error

An error is defined as an unexpected, invalid program state from which it is impossible to recover. For the sake of definition, recovery scope is defined as the method scope. Incomplete recovery is considered a recovery.

One pretty straightforward example for an error:



<?php



/*

 * Connect to Specified Database

 *

 * @throws Example_Datasource_Exception when it can't connect

 * to specified DSN.

 */

function connectDB($dsn) {

    $this->db =& DB::connect($dsn);

    if (DB::isError($this->db)) {

        throw new Example_Datasource_Exception(

                "Unable to connect to $dsn:" . $this->db->getMessage()

        );

    }

}

?>

In this example the objective of the method is to connect to the given DSN. Since it can't do anything but ask PEAR DB to do it, whenever DB returns an error, the only option is to bail out and launch the exception.The next example will introduce the concept of recovery:



<?php



/*

 * Connect to one of the possible databases

 *

 * @throws Example_Datasource_Exception when it can't connect to

 * any of the configured databases.

 *

 * @throws Example_Config_Exception when it can't find databases

 * in the configuration.

 */



function connect(Config $conf) {

    $dsns =& $conf->searchPath(array('config', 'db'));

    if ($dsns === FALSE) throw new Example_Config_Exception(

        'Unable to find config/db section in configuration.'

    );



    $dsns =& $dsns->toArray();

    

    foreach($dsns as $dsn) {

        try { 

            $this->connectDB($dsn);

            return;

        } catch (Example_Datasource_Exception e) {

            // Some warning/logging code recording the failure

            // to connect to one of the databases

        }

    }

    throw new Example_Datasource_Exception(

        'Unable to connect to any of the configured databases'

    );

}

?>

This second example shows an exception being caught and recovered from. Altough the lower level connectDB method is unable to do anything but throw an error when one database connection fails, the upper level connect method knows the object can go by with any one of the configured databases. Since the error was recovered from, the exception is silenced at this level and not rethrown.

The last example illustrates incomplete recovery:



<?php



/*

 * loadConfig parses the provided configuration. If the configuration

 * is invalid, it will set the configuration to the default config.

 *

 */

function loadConfig(Config $conf) {

    try {

        $this->config = $conf->parse();

    } catch (Config_Parse_Exception e) {

        // Warn/Log code goes here

        // Perform incomplete recovery

        $this->config = $this->defaultConfig;

    }

}

?>

The recovery produces side effects, so it is considered incomplete. However, the program may proceed, so the exception is considered handled, and must not be rethrown. As in the previous example, when silencing the exception, logging or warning should occur.

Error Signaling in PHP5 PEAR packages

Error conditions in PEAR packages written for PHP5 must be signaled using exceptions. Usage of return codes or return PEAR_Error objects is deprecated in favor of exceptions. Naturally, packages providing compatibility with PHP4 do not fall under these coding guidelines, and may thus use the error handling mechanisms defined in the PHP4 PEAR coding guidelines.

An exception should be thrown whenever an error condition is met, according to the definition provided in the previous section. The thrown exception should contain enough information to debug the error and quickly identify the error cause. Note that, during production runs, no exception should reach the end-user, so there is no need for concern about technical complexity in the exception error messages.

The basic PEAR_Exception contains a textual error, describing the program state that led to the throw and, optionally, a wrapped lower level exception, containing more info on the lower level causes of the error.

The kind of information to be included in the Exception is dependent on the error condition. From the point of view of exception throwing, there are three classes of error conditions:

Errors detected during precondition checks

Lower level library errors signaled via error return codes or error return objects.

Uncorrectable lower library exceptions.

Errors detected during precondition checks should contain a description of the failed check. If possible, the description should contain the violating value. Naturally, no wrapped exception can be included, as there isn't a lower level cause of the error. Example:



<?php



function divide($x,$y) {

    if ($y == 0) throw new Example_Aritmetic_Exception('Divide by zero');

    return $x/$y;

}

?>

Errors signaled via return codes by lower level libraries, if unrecoverable, should be turned into exceptions. The error description should try to convey all information contained in the original error. One example, is the connect method previously presented:



<?php



/*

 * Connect to Specified Database

 *

 * @throws Example_Datasource_Exception when it can't connect to specified DSN.

 */

function connectDB($dsn) {

    $this->db =& DB::connect($dsn);

    if (DB::isError($this->db)) {

        throw new Example_Datasource_Exception(

                "Unable to connect to $dsn:" . $this->db->getMessage()

        );

    }

}

?>

Lower library exceptions, if they can't be corrected, should either be rethrown or bubbled up. When rethrowing, the original exception must be wrapped inside the one being thrown. When letting the exception bubble up, the exception just isn't handled and will continue up the call stack in search of a handler.

One example for rethrowing:



<?php



function preTaxPrice($retailPrice, $taxRate) {

    try {

        return $this->divide($retailPrice, 1 + $taxRate);

    } catch (Example_Aritmetic_Exception e) {

        throw new Example_Tax_Exception('Invalid tax rate.', e);

    }

}

?>

And the same example for bubbling up:



<?php



function preTaxPrice($retailPrice, $taxRate) {

    return $this->divide($retailPrice, 1 + $taxRate);

}

?>

The case between rethrowing or bubbling up is one of software architecture: Exceptions should be bubbled up, except in these two cases:

The original exception is from another package. Letting it bubble up would cause implementation details to be exposed, violating layer abstraction, conducing to poor design.

The current method can add useful debugging information to the received error before rethrowing.

Exceptions and normal program flow

Exceptions should never be used as normal program flow. If removing all exception handling logic (try-catch statements) from the program, the remaining code should represent the "One True Path" -- the flow that would be executed in the absence of errors.

This requirement is equivalent to requiring that exceptions be thrown only on error conditions, and never in normal program states.

One example of a method that wrongly uses the bubble up capability of exceptions to return a result from a deep recursion:



<?php



/**

 * Recursively search a tree for string.

 * @throws ResultException

 */

public function search(TreeNode $node, $data)  {

    if ($node->data === $data) {

         throw new ResultException( $node );

    } else {

         search( $node->leftChild, $data );

         search( $node->rightChild, $data );

    }

}

?>

In the example the ResultException is simply using the "eject!" qualities of exception handling to jump out of deeply nested recursion. When actually used to signify an error this is a very powerful feature, but in the example above this is simply lazy development.

Exception class hierarchies

All of PEAR packages exceptions must be descendant from PEAR_Exception. PEAR_Exception provides exception wrapping abilities, absent from the top level PHP Exception class, and needed to comply with the previous section requirements.

Aditionally, each PEAR package must provide a top level exception, named <Package_Name>_Exception. It is considered best practice that the package never throws Exceptions that aren't descendant from its top level exception.

Exception silencing (Section placeholder)

This section will contain the requirements related to Exception silencing. Wether to support exception silencing or not is a cause for debate, and a vote will happen after (if) the main text approval. Supporting exception silencing, depending on PHP support for canceling throws, may require that an Exception throw be done via a PEAR_Exception method (PEAR_Exception::throw) which optionally silences the exception and allows the program to flow normally.

Documenting Exceptions

Because PHP, unlike Java, does not require you to explicitly state which Exceptions a method throws in the method signature, it is critical that Exceptions be thoroughly documented in your method headers.

Exceptions should be documented using the @throws phpdoc keyword:



<?php



/**

 * This method searches for aliens.

 *

 * @return array Array of Aliens objects.

 * @throws AntennaBrokenException If the impedence readings indicate

 * that the antenna is broken.

 *

 * @throws AntennaInUseException If another process is using the

 * antenna already.

 */

public function findAliens($color = 'green');

?>

In many cases middle layers of an application will rewrap any lower-level exceptions into more meaningful application exceptions. This also needs to be made clear:



<?php



/**

 * Load session objects into shared memory.

 *

 * @throws LoadingException Any lower-level IOException will be wrapped

 * and re-thrown as a LoadingException.

 */

public function loadSessionObjects();

?>

In other cases your method may simply be a conduit through which lower level exceptions can pass freely. As challenging as it may be, your method should also document which exceptions it is not catching.



<?php



/**

 * Performs a batch of database queries (atomically, not in transaction).

 * @throws SQLException Low-level SQL errors will bubble up through this method.

 */

public function batchExecute();

?>

Exceptions as part of the API

Exceptions play a critical role in the API of your library. Developers using your library depend on accurate descriptions of where and why exceptions might be thrown from your package. Documentation is critical. Also maintaining the types of messages that are thrown is also an important requirement for maintaining backwards-compatibility.

Because Exceptions are critical to the API of your package, you must ensure that you don't break backwards compatibility by making changes to exceptions.

Things that break BC include:

Any change to which methods throw exceptions.

A change whereby a method throws an exception higher in the inheritance tree. For example, if you changed your method to throw a PEAR_Exception rather than a PEAR_IOException, you would be breaking backwards compatibility.

Things that do not break BC:

Throwing a subclass of the original exception. For example, changing a method to throw PEAR_IOException when before it had been throwing PEAR_Exception would not break BC (provided that PEAR_IOException extends PEAR_Exception).

mgm grand market

PEPr Proposal [105]: Database::Sqlite_Tools

2004-07-03T21:54:01-05:00

Proposed package: Database::Sqlite_Tools

Proposer: David Costa

Sqlite_Tools

Intro

Sqlite is a lightweight embedded database library. It is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine and is included by default with PHP 5.

Sqlite_Tools is an object oriented interface to effectively manage and backup Sqlite databases.

Why SQLite Tools

The stregth of Sqlite and its superb portability might also be seen as a weakness. Because each database is

self contained in a file we do have a single point of entry and a single point of failure.

Client-Server relational databases implements a number of build-in features to make the db corruption a remote occurance.

Whilst Sqlite does offer some similar functionality (e.g. synchronous value), there are no PHP functions in this directions and there is little knowledge on how to successfully maintain and backup multiple database insuring the integrity of the initial and cloned database.

Sqlite_Tools functions

Sqlite_Tools functionality can be summarized in two different branches:

Database Manipulation and Maintenance

checkIntegrity : checks the integrity of one or more databases see the live example

cacheSize : checks or reset the default cache size in one ore more databases see the live example

Sync: checks or rest the synchronous value in one more more databases see the example

dbFileInfo: Fetch all the available information in one more more databases filessee the example

copySafe: performs a safe copy for a database, checks integrity on the cloned database

and others, each of the function is well commented so you should be able to understand its purpose.

Database backup or remote live replication

ftpBackup : backups one or more databases via ftpsee the example

localRsync: Rsync a database path locally, requires Rsync lib

remoteRsync: launch a local Rsync deamon for the purpose of remote synchronization (experimental function)

XMLDump : creates an XML dump of one or more databases see the example

Sqlite_Tools Output and Usage

Because Sqlite_Tools is a library its output for mostly of the function is basically raw and can be used in connection with the logs function which keeps each of the operations (e.g. database opened, database integrity check, database backup on ftp performed) output in a local sqlite logs database.

On the source link below you can see a number of usage examples.

Updated 11 July 2004

Removed some of the constants

as suggested by Hans

PEPr Proposal [60]: RFC::How the QA Team will work.

2004-04-26T17:28:16-05:00

Proposed package: RFC::How the QA Team will work.

Proposer: Helgi Þormar Þorbjörnsson

PEPr Proposal [58]: Console::Console_Getargs

2004-04-21T14:11:34-05:00

Proposed package: Console::Console_Getargs

Proposer: Bertrand Mansion

PEPr Proposal [18]: Configuration::Config_Registry

2004-02-01T14:46:16-05:00

Proposed package: Configuration::Config_Registry

Proposer: Laurent Laville

PEPr Proposal [14]: Database::DB_Table

2004-01-02T01:32:35-05:00

Proposed package: Database::DB_Table

Proposer: Paul Jones