Paul M. Jones

Really, if you're not reading Ryan King on a regular basis, you're missing a lot of good thinking. In this post, he points to work from Clay Shirky (a true visonary and excellent essayist).

Clay's essay is about hierarchical organization versus user-defined relationships. This is one of the differences between Yahoo (who did a "big up front design" on their catalog to tell you where things go so that the stack "makes sense") and Google (who don't organize at all, they let you sift instantly through the stack). I quote:

Browse versus search is a radical increase in the trust we put in link infrastructure, and in the degree of power derived from that link structure. Browse says the people making the ontology, the people doing the categorization, have the responsibility to organize the world in advance. Given this requirement, the views of the catalogers necessarily override the user's needs and the user's view of the world. If you want something that hasn't been categorized in the way you think about it, you're out of luck.

The search paradigm says the reverse. It says nobody gets to tell you in advance what it is you need. Search says that, at the moment that you are looking for it, we will do our best to service it based on this link structure, because we believe we can build a world where we don't need the hierarchy to coexist with the link structure.

A lot of the conversation that's going on now about categorization starts at a second step -- "Since categorization is a good way to organize the world, we should..." But the first step is to ask the critical question: Is categorization a good idea? We can see, from the Yahoo versus Google example, that there are a number of cases where you get significant value out of not categorizing. Even Google adopted DMOZ, the open source version of the Yahoo directory, and later they downgraded its presence on the site, because almost no one was using it. When people were offered search and categorization side-by-side, fewer and fewer people were using categorization to find things.

Read the whole thing.

Tomorrow I'll be going to PHP Tropics as both a vacation and as professional development. Woohoo! :-)

And on a professional note: If I have not responded to your emails to me about Solar, Text_Wiki, Savant, DB_Table, or any of my other projects, please accept my apologies. I've been horribly busy with my MBA classes and "real" (paying) work and family duties, so everything else has had to sit by the wayside for now. After I get back from Cancun I'll be able to respond with my prior speed (such as it was).

For various reasons, I have purchased a new Mac Mini to take the place of my older Cube, originally purchased in late 2000. (Loud scraping noises from the old hard drive were the last warning I needed -- second hard drive I've had to replace lately.)

It's wonderful. I swear to Jebus it's under two inches tall, and just wide enough to take a slot-loading CD/DVD. Built-in Airport and Bluetooth. Just finished putting my databases back in place from backup. Whisper-quiet. Didn't come with OS X 10.4 installed, but they gave me an upgrade DVD; no big deal on the installation, I usually wipe out any new machine anyway and reinstall from scratch.

The only downside was I had to buy a DVI-to-ADC converter to keep using the older Apple LCD Cinema Display.

Solar is a simple object library and application repository for PHP5 under E_STRICT. It takes hints from PEAR and Horde, and bears some superficial resemblance to Ruby on Rails for its MVC application directory structure.

API documentation is becoming voluminous, and is bundled with the package now, along with an example Solar.config.php file.

The change notes for this release are:

* WARNING: This is a public development release, and is not
    yet stable.

* API documentation is now distributed with Solar
    installations; this accounts for 90% or more of the
    package size.  Look in your PEAR docs/ directory for the
    new files.

* Added a Solar.config.php example to documentation.  Look
    for it in your PEAR docs/ directory.

* Added Solar_Template class (is an extended and customized
    Savant3 class).  Savant3 is now distributed in the
    Template/ directory.

* Solar_App:

    * Converted $action_src, $action_var, and
        $action_default to array keys ($action['src'],
        $action['var'], $action['default']).

    * Added a $view property (is a reference to the shared
        object called 'template'; i.e., a Solar_Template
        object).  Sets up the views directory
        (template_path) automatically, and sets up the added
        paths for user-developed themes automatically.

    * Calling view() now returns the output of the named
        named view, not the path to the file for that view.

    * Calling model() now returns a new instance of the
        named model, instead of the path to the file for
        that model.

* Converted Solar_App_Bugs and Solar_App_Bookmarks to use
    the new and different Solar_App features for $action,
    $view, and view().

* Solar_Cache_File:

    * Now uses '.serial' as the filename extension for
        serialized files no matter what

    * No more prefixing of file names

    * Config values are transferred to protected properties
        so they cannot be changed after instantiation

    * Creates the cache directory if it does not already
        exist.

    * Always hashes the cache entry key (prevents directory
        traversals)

* Solar_Cache_Mem renamed to Solar_Cache_Memcache.

* Solar_App_Bookmarks: if you try to QuickMark a URI that
    you already have bookmarked, you are redirected to that
    entry in your bookmarks (instead of it being stored more
    than once).

* Solar_Sql_Driver: now uses lazy connections. it connects
    at exec() time instead of __construct() time.  This puts
    the speed hit of connecting to the database until the
    last possible instant, which means merely instantiating
    an Sql object should not slow you down.

This month's International PHP Magazine has my article on Yawp; woohoo! :-)

Yawp (for PHP4 and non-strict PHP5) is a single PEAR-compliant class that encapsulates a number of other PEAR classes, and ties them all together with a simple configuration file. When you use Yawp as the base of your application, you get...

    * A single easy-to-edit config file
    * Automated authentication processing
    * Automatic creation of common objects:
          o Database abstraction layer
          o Disk cache
          o Composite logger
          o Benchmark timer
          o Variable dumper
    * Safe accessor methods for PATH_INFO, GET, POST, and configuration values

Be sure the visit the Yawp website for full API and user documentation.

Regarding the latest release of Solar, Atrus asked: "How is this significantly different from PEAR?"

It's a good question. Let me outline some of what I think are the major differences. Please note that with maybe one exception, none of this is intended as criticism of PEAR, only as description. You can figure out for yourself where the criticism lies.

1. As Atrus noted, Solar is built from the ground up for E_STRICT compliance in PHP5, which makes it incompatible with PHP4.
2. Having said that, Solar is very much like PEAR in concept, in that one of its goals is to be a class library providing common web application functions: error handling, user authentication, querying SQL sources, OR mangement, and so on. However, Solar differs from PEAR in execution of that concept:
   • All class constructors have identical parameters (a single associative array).
   • Almost all Solar classes are extended from a single base class. The base class is relatively light and provides common functionality such as error generation and localization string handling. This means that all Solar classes have localization built in from the start. (Some classes are not extended from the base class; typically, these classes are collections of static methods.)
   • The classes are much more consistent with each other because they are the product of one coder (your humble servant).
   • The code is better-commented, easier to read, simpler, and more straightforward than most of what is found in PEAR.
3. Solar is quite different from PEAR in that it is also a framework.
   • Yawp was my one attempt at building a straightforward and comprehensible foundation for rapid application development out of PEAR components. While Yawp is moderately successful at this, the inconsistency between PEAR classes makes it necessary to custom-code the "glue" between those classes so they can interoperate. With Solar, the classes are all so similar in implementation that it is much easier to make them interoperate.
   • As a framework, Solar has a consistent and extensible configuration mechanism that is identical for each class in the system; PEAR does not have such a mechanism.
   • Solar provides built-in methods for safe retrieval of user-provided variables and configuration values; PEAR does not.
4. Solar provides mid-level independent application components out of the box (these are called Solar Cells). For example, there is a universal tagging mechanism, a combined comments/trackback storage system, a bug-tracking entity, and so on. Combining these components with a little procedural glue (e.g. in a controller action) gets you a lot of good functionality in a much less time. PEAR has no such unified component mechanism that I know of (happy to be proved wrong here).
5. Solar comes with useful applications out-of-the-box (a bug tracker and a del.icio.us-like bookmark system) with more on the way, such as blog and wiki. With the one exception of phpDocumentor, PEAR does not. You might say that the "AR" in Solar is actually true. ;-) In this way, Solar might be more like Horde than PEAR.
6. The communities are very different. PEAR is a mishmash of developers with their own goals and desires, driven by a voting system for new packages, herded like cats by an unelected Group that prefers to force collaboration under a rule of seniority, and with various (probably unfixable) flaws in the social norms; in other words, it is much like elitist democracy or mob rule under appointed oligarchy. Solar is more like beneficent dictatorship where the main rule is "be nice." ;-)
7. Last but not least: PEAR has been in place for a few years now, and Solar is very young (first release was only 2 months ago). If you want to get in on the ground floor of a growing community of PHP5 developers and make a difference in a new project, this might be the place for you. Sign up for the mailing list at the Solar home page: http://solarphp.com.

Busy weekend; lots of MBA coursework completed, and three releases of Solar. This one is a combined bugfix and function enhancement. Change notes are:

* WARNING: This is a public development release, and is not
yet stable.

* Removed notify() method and related properties from
Solar_Cell_Comments, as that method is more properly in
the realm of the application (which may notify in many
different ways, if at all).

* Added setup() method to Solar_App for easier setting of
initial property values in extended classes (e.g., you
can use functions this way).  Added per discussion with
Bhishma Parva (thanks for pointing it out).

* Solar_Uri now automatically urlencodes query and pathinfo
values at export() time.

* Solar_App_Bookmarks now gives the correct backlink in
edit.php view (because of the new Solar_Uri automatic
urlencoding).

* Solar_Cell_Bugs now shows priority options.

* Solar_Cell_Bugs edit form now allows editing of the summary.

Bug tracking for Solar is now available at http://solarphp.com/bugs.php. This is the proof-of-concept Solar_App_Bugs application (eat your own dog food, right?).

Solar is a simple object library and application repository for PHP; Solar applications bear some superficial resemblance to Ruby on Rails. Above all, Solar code is comprehensible and easy to understand, even for the relatively new PHP programmer, because it is exceptionally well-commented and adheres to a simple, straightforward style.

This is a bugfix release. You really should join the Solar mailing list; some good info on setting up Solar.config.php is there.

The changes notes for this release are:

* WARNING: This is a public development release, and is not
yet stable.

* Solar::start() now automatically shares and starts a Solar_User
object ('user') ... this makes sure authentication is always
processed.

* Solar_App::automap() now only attempts scandir() if the
requested directory actually exists.

* Solar_App_Bugs controllers for edit.php and item.php would
try to add the bug summary as the comment subject line,
but the max subject line is 64 chars (the max summary is
255) ... this would cause silent errors and fail to add
the comment.  S_A_Bugs no longer adds a subject line,
which seems to correct the issue.

Well, I just signed up for PHP Tropics conference in Cancun being held by PHP Architect. This is my first PHP conference, and I'm really looking forward to meeting in person some of the people with whom I have corresponded for so long. And goodness knows I need a vacation. :-)