To show off the new library, I've added a "quick add" feature to Nag, the Horde task manager. This adds a tasks/quickAdd registry method, that takes a single string. Dates in the string are parsed out as due dates, and multiple tasks can be added by separating them with newlines. Child tasks can also be created with indentation (including * or - lists).

For example:

laundry tomorrow
* buy detergent tonight 

Will create two tasks: a parent task named "laundry" with a due date of tomorrow, and a child task named "buy detergent" with a due date of tonight.

In addition to the API call there's a pretty UI for this:

Gives:

Others have these features of course. However our version handles some cases that some of them don't:

After a little hacking, the Horde_Controller package in git now has Cli request and response objects and this script is all you need to give command-line access to a set of controllers:

#!/usr/bin/env php
<?php

require 'Horde/Autoloader.php';

// Set up our request and routing objects
$request = new Horde_Controller_Request_Cli();
$response = new Horde_Controller_Response_Cli();
$mapper = new Horde_Routes_Mapper();
$mapper->connect(':controller/:action');

// Create our controller context.
$context = array(
    'mapper' => $mapper,
    'controllerDir' => dirname(__FILE__) . '/../lib/controllers',
);

// Dispatch.
try {
    $dispatcher = Horde_Controller_Dispatcher::singleton($context);
    $dispatcher->dispatch($request, $response);
} catch (Exception $e) {
    var_dump($e->getMessage());
}

Error handling can obviously be improved, and your controllers need to produce plaintext output for this to be friendly, but it gives you the flexibility to add new commands to your script just by dropping in new controller classes to the controllerDir.

Arguments are parsed with the Horde/Argv package, using a new allowUnknownArgs parameter that auto-creates simple text values for options unknown to the parser. This lets you take arbitrary command line arguments in your controller without having to tell the dispatcher script what arguments you expect ahead of time (of course the trade off is that the dispatcher can't validate the arguments, so the controllers are responsible for that, just like they are with web requests).

Here's an example of invoking the index() method of a MigrateController class:

$ ./dispatch.php migrate

To invoke the currentVersion() method of the same controller:

$ ./dispatch.php migrate/current_version

To pass an argument named target_version with the value "11" to the controller's index() method:

$ ./dispatch.php migrate --target-version=11

It's still a work in progress, but I'm happy with the possibilities.

Chora provides a traditional tree-based view of the repository, with histories available in each individual file. We'll definitely have commit-based information (as we already support changesets in CVS and patchsets via cvsps), and we're looking at having more of a git-centric history view as well. But if you need to interface with your repository through PHP code, or if you're used to a primarily tree-based version control browser, or if you already use Chora or Horde, you might find this useful.

1. Write down the new coding standards for Horde 4 libraries. These have been developing somewhat organically, but they need to be codified - what is the package layout, what capitalization, what PHP 5 features to emphasize, what not to use, etc.
2. Focus on converting our existing libraries. Libraries will be moved to the main git repository when:
   1. The code has been reviewed, updated for the new coding standards, potentially refactored
   2. Unnecessary dependencies have been eliminated
   3. Wherever possible they should work without assuming a Horde configuration, $registry instance, etc.
   4. There should be at least basic unit tests
3. When a library is moved to git, it will be deleted from CVS HEAD
4. Applications will be tweaked (in CVS) to work with the newly refactored Horde 4 packages

Some libraries (Autoloader, Log, Support, ...) are already in git as they are already Horde 4 code; several others such as Db, Feed, Argv, ... will join them soon in the move from CVS. The rest - all 80-some other libraries in the current Horde Framework - will be converted over next.

So it was great to see not only Horde, but Jan, get a really nice interview in Techworld Australia. Thanks Jan, and everyone working on Horde. The future looks great.

• Move to git for future (Horde 4+) version control. Code will be pushed to a clean git repository as it is modified for Horde 4 and PHP 5. Git pushes will generate email to a new list, commits@lists.horde.org. Everything currently in CVS will remain available, and Horde 3.x will continue to be developed in and released from the existing CVS structure.
• Aim for shorter release cycles of major versions. When backwards compatibility is broken we will increment the major version number (Horde 3 to Horde 4) as we do now; we'll just do that more often. Feedback indicates that being able to do feature upgrades of an application but not Horde, or vice versa, is not a big advantage for most people.
• Use individual package versions much more extensively with Horde 4. We want it to be possible to release an application upgrade that relies on new framework functionality without requiring a new major version; instead, many changes will be possible by just requiring a specific package version.
• Finally, and most importantly, we will be focusing on getting the last Horde 3.3 releases out (see http://wiki.horde.org/ReleaseManagement), and then shifting our major focus to Horde 4. Our goal is to have an initial release of Horde 4.0 within 6 months of starting serious development on it; and to aim for major version releases approximately every year thereafter.
  

The full minutes are available in the board list archives; thanks to Ben Klang for running the meeting, posting the minutes, and doing the initial summarization.

We're going to skip the details of why the simplistic ways to do this are a bad idea, and go right to consistent hashing.

If you're not familiar with it already, you should read up to understand what it solves and how it works. Once you have that covered, here's how you can do it using Horde_Support_ConsistentHash, part of the recently released horde/support package.

For our example, you have three cache servers; the third one is much more powerful so you'd like it to handle the bulk of users. You're going to distribute cached user data across them based on username. Easy does it:

$h = new Horde_Support_ConsistentHash;
$h->add('cache1.example.com', 1);
$h->add('cache2.example.com', 1);
$h->add('cache3.example.com', 4);
$cacheServer = $h->get($username);

This has all kinds of nice properties: you can bring up new servers gradually by increasing their weight (just read the list of nodes from a database or configuration file), and doing so - or taking a bad server out of the pool - won't cause most users on an unaffected server to be switched, reducing cache thrashing and probably saving your butt if you really have as much traffic as you think you do.

Horde_Support_ConsistentHash has no external dependencies (even on other Horde_Support files) and can be installed with an easy:

pear channel-discover pear.horde.org
pear install horde/support-beta

Finally, if your cache backend is memcache, the PECL memcache extension can take care of this for you by setting memcache.cache_strategy = "consistent". Obviously the Horde implementation can help you out in far more situations than just memcache, or if you're stuck with an older memcache package.