Tias’ PEAR blog

A few days before opening this blog I released PEAR_Frontend_Web, version 0.7.0

I started working on PEAR_Frontend_Web after making go-pear more robust. go-pear automatically installs PEAR_Frontend_Web, which I found to have an amazing potential, but a horrible implementation: It used the (extremely slow) ‘list-all’ command for _everything_ even for listing the locally installed packages !

So I started fixing some of the most obvious, real bugs. The lead for the package was Gregory Beaver (cellog), but he wasn’t active on it. After submitting a few bugs he asked if I wanted to maintain the webfrontend, ofcourse I did ; )

Since then I’ve rewritten most of the essential things:

It now uses local commands as much as possible and it doesn’t use the old-style DHTML hooks anymore.

It is channel independant: The webfrontend was written in the time that there was only one channel: pear.php.net. At a given moment I was thinking about how to make it possible to easely switch channels. That’s when I decided that I didn’t want to switch channels like in the command-line PEAR, I wanted to manage all channels at the same time !
This is a feature that is, for me, reason enough to use the webfrontend over the CLI.

Speed was very important to me, so I changed some of the PEAR commands themselves: The ’search’ features uses ‘list-all’ and was, too, horribly slow. Even if you only searched in the package names, _all_ full package information was downloaded. A simple check speeded this up significantly. The last thing that used list-all was list-all itself. The webfrontend used paging on the output of list-all, so it really didn’t have to download all that info. Instead of reworking the paging, I decided to create 3 new commands: list-packages (lists the packages of a channel), list-categories (lists the categories of a channel ; ) and lastly list-category <category> which shows all package information of one category, which is a lot faster to show.

I also created an online docviewer. When I install I package I quickly want to know how it works, what has to be done etc, for that you have to read the docs. To make that easy, I made it possible to view the docs throught the webfrontend.

Lastly there is security, this is a big issue for a webapp that allows you to manage an entire package management system. In the README there is decribed how to protect your webapp with a .htaccess password, I’ve created a check to make sure that people don’t just ignore this, and possibly find themselves with a defaced system.

Actually, the webfrontend is much more then a webfrontend now. I love to call it the ’webbased package manager for PEAR-compatible packages’. The webfrontend of PEAR is like the synaptic of APT, maybe even better ; )

You can find a demo of the webfrontend at: http://tias.ulyssis.org/frontweb_demo/

I like the installation process of Wordpress (this blog software), just like Drupal, it does what I call a `pure` install: you just need to enter the database connection settings (and your email).

Imagine this information would be already in PEAR, and that you could choose in which directory it should be installed: this would be the perfect webapp to be in a PEAR package. Installation would be a breeze and it would be upgraded like any other PEAR package…

I’ve created this blog to talk about interesting things that are happening in and around PEAR.

It will mostly be about exiting things I’m working on, like go-pear, PEAR_Frontend_Web and PEAR itself.