With the recent flurry of development activity over at the Horde Project, there came an increase in the number of topic branches in our git repository.  One of the problems dealing with longer living topic branches is the question of how to keep the topic branch in sync with changes going on in the master branch. 

The best way to do this is to rebase the topic branch from master and then rebase your tracking branch against the remote topic branch.  The problem with doing this is that if you are using a post-receive hook to send out commit announcement emails, pushing your changes back to the server will result in duplicate commit messages being sent for the changes that were rebased from origin.  This makes it difficult to zero in on what the actual relevant change in the topic branch is.

After some digging around in the git documentation and some hacking on the script we use for commit messages, we have come up with a good-enough solution. The git cherry can examine the change sets between the two branches and detect if a specific commit on one branch is present on the other branch or not. What makes this so useful is that it doesn't compare commit ids, since these will be different, it actually looks at the diff of each changeset to see if they are the same change.

You can look at the full post-receive-email script we use by looking at our horde-support repository, but the basic idea is to call git cherry like so:

and then iterate over the results, ignoring any commit ids that are prefixed with a '-'.

So now, my typical development session might go something like this (some commands added for clarity):

There's been a flurry of recent "infrastructure" activity over at The Horde Project. One such activity has consolidated the two main code repositories. The horde-hatchery repository has been imported, along with all the history, into the main horde repository. Many thanks to Michael Slusarz for getting this done.

Along with this consolidation, come some improvements to the process of setting up a horde development environment. There is still ongoing discussion as to what the final solution will be, and, as with any big change, there are still some things to be worked out, but hopefully this lowers the barrier for interested developers to get involved in Horde development. See http://horde.org/source/git.php for more information.

Additionally, the scripts that automatically generate the documentation at http://dev.horde.org have been tweaked a bit. We now generate documentation for all code in our git repository, as well as all the code in the stable, H3 line. We are now also generating development snapshots of the main-line H4 applications and libraries.

Some might also notice performance improvements when accessing our services such as bug tracking, source code browsing or our wiki. These services were recently migrated to a more capable server. Thanks to Ben Klang and Alkaloid networks for the server space.

Wow, it's been since June 10th, almost 4 months since my last entry. Time flies...especially when you are busy. In the interest of keeping people informed, here are some of the new things I've been working on with regards to The Horde Project,  with an indication as to what version of Horde the work applies to:

Horde_Service_Twitter (H4 Only)

Since stating to use twitter, I figured it would be helpful to have my Twitter timeline appear in Horde, since that's what is usually loaded in my browser. Following my typical NIH rule when it comes to Horde, the result is the new Horde_Service_Twitter library and the twitter_timeline block for Horde's portal.  Horde_Service_Twitter supports authentication to Twitter via both the standard http authentication method as well as via OAuth. The latter making use of the Horde_Oauth library. The portal block allows you to publish a new tweet,  shows the most recent tweets by the people you are following and allows you to reply to a displayed tweet.

The addition of Horde_Service_Twitter, along with Horde_Service_Facebook, adds some exciting possibilities for integration points with other Horde applications. Horde already has some address book and calendar integration with Facebook, but other possibilities include things like automatically posting a notification to Twitter or Facebook when a set of new images are uploaded to Ansel, or maybe when a new blog post is published with Jonah.

Ansel (H3 and H4)

Ansel has gotten a fair amount of work recently and is ready for a 1.1 release. The most obvious change is full support of geo-tagging features.  Ansel has always been able to read,and display an image's meta data...but up until now you couldn't do much with any of the location data. Now, Ansel will recognize GPS coordinates in the meta data and display small thumbnails of those images in an embedded Google Map. There are various locations throughout Ansel where you can view these maps. You can also add location data to images that do not contain it as well as edit any existing location data. Full support for reverse geocoding means that you can (re)tag an image by either typing a textual name for the location (such as Philadelphia, PA) or by typing in actual GPS lat/lng coordinates. Of course, you can also (re)tag an image simply by browsing the Google Map and clicking where you want the image to be located.

Ansel's bleeding edge code has officially moved out of Horde's CVS repository and into the git repository, horde-hatchery. A fair amount of refactoring and internal improvements have already been done in getting Ansel and Horde_Image ready for Horde 4. Among these changes is better support for image meta data, with a new driver based on exif tool. This allows recognition of not only EXIF tags, but also IPTC and XMP data as well.

iPhoto/Aperture Export Plug-Ins (H3 and H4)

Related to the Ansel application, are new export plug-ins for both of Apple's image management applications, iPhoto and Aperture.  Currently available via Horde's horde-hatchery git repository, these plug-ins allow you to upload your images directly to an Ansel server from within iPhoto or Aperture. All meta data is retained when uploaded, including keywords that added using Aperture or iPhoto. You are able to create new galleries from the plug-in's interface, browse thumbnails of existing Ansel galleries (to see what images you have previously uploaded), and choose if the images should be resized (and to what size) before uploading.  Both plug-ins support configuring multiple Ansel servers if you happen to have access to different installations.

Even though these live in horde-hatchery, they will work with both Ansel 1.x as well as the bleeding edge Ansel code that lives in  the hatchery. The iPhoto exporter supports iPhoto '08 and later, and the Aperture exporter is written for Aperture 2.1 or later.  Both require OS X 10.5 or later. They should run on either PPC or Intel hardware, but have only been tested on Intel. Currently they are available only as source (which can easily be compiled using XCode) but a development build should be available shortly.

Kronolith (H4 only)

I've been tasked with adding support for resource scheduling to Kronolith, and the work is mostly complete. Resources may be invited to events by the event organizer using the existing attendees interface. Resources can be set up to automatically determine if they are available, and respond to the request automatically. There is also support for resource groups. Resource Groups are just a grouping of resources that are similar. When a group is invited to a meeting, the first available resource from that group will accept the invitation. For example, you have 10 projectors available and it doesn't really matter which projector is used for a meeting. Instead of going through all the projectors to see which one is available, you can just invite the projector group to the event. The first projector that is available during the meeting time will accept the invitation.

During some recent quality-time I spent with my schedule (read: "trying to figure out how to add more time to a day"), I had an a-ha moment. Why am I switching back and forth between weather data and my calendar to see the weather for a day of interest in my calendar? Why can't it just display in the calendar?  We already have some code in Horde that interfaces with the weather.com API (thanks to PEAR's Services_Weather package), so why not provide the weather data via the listTimeObjects API so Kronolith can pick it up?

The first step along this path was to create a new "mini" application - or an application that does nothing other than expose data via the listTimeObjects API. This resulted in the lightweight TimeObjects application that now lives in the horde-hatchery git repository.  This does put another level of abstraction between the weather data and Kronolith, but what I didn't want to do was start a trend of having to write a new Kronolith Event driver for any new type of time data that might be desired.  With TimeObjects, now all that is needed is to drop a new driver into TimeObjects' lib/Driver/ directory and it will be picked up and exposed via the API.

With the addition of the new TimeObjects application, Kronolith can now display the forecast data for up to the next 5 days directly in the calendar view. The high/low temperature along with the general conditions for that day are displayed, with a tooltip popup showing more detail. Currently, for this to work, you will need a contact in Turba that is marked as your own and containing enough of your location information to satisfy weather.com's service. Horde will also need to be configured with the weather.com api keys...just like the weather.com block requires. A future addition will be to allow choosing (multiple?) locations via a Google map in Horde's preferences.

Since the listTimeObjects API really isn't documented anywhere other than our source code, a little introduction may be in order.  If you are not interested in Horde internals, you can skip to the end.

The API allows any Horde application to expose it's data as events to be displayed in Kronolith.  For example, via this API, Turba can provide the data needed to display contact birthdays and anniversaries in Kronolith.  Nag can display task due dates etc... For this to work,  an application needs to expose two methods via it's own API: listTimeObjectCategories(), which returns the categories of time objects available (birthday, anniversary etc..) and listTimeObjects() which returns the actual data.  The data returned includes information such as the start and end times, a title, a description, icon, and link.  For more information I will direct you to the phpdoc at http://dev.horde.org.

As always, a warning that the TimeObjects code is Horde 4 only, and as such is not considered stable.

There are now two new Horde merchandise shops open. These Spreadshirt shops are in addition to the existing CafePress shop we have.

The shop at horde.spreadshirt.net is for our European customers - as there will be no additional taxes or custom charges. The other shop is at horde.spreadshirt.com and is for our USA customers. Both shops offer flock printed polo shirts and T-shirts as well as some other cool stuff!