The tooling has involved a few challenges however, since Jasig (the organization that hosts the CAS and phpCAS projects) uses Subversion for its source-code repositories and we use Git for all of our projects. Now, I could just suck it up and use Subversion when doing phpCAS development, but there are a few reasons I don’t:

1. We make use of Git submodules to include phpCAS along with the source-code of our applications, necessitating the use of a public Git repository that includes phpCAS.
2. The git-svn tools allow me to use git on my end to work with a Subversion repository, which is great because…
3. I find that Git’s fast history browsing and searching make troubleshooting and bug fixing much easier than any other tools I’ve used.

For the past two years I have been using git-svn to work with the phpCAS repository and every so often pushing changes up to a public Git repository on GitHub. Our applications reference this repository as a submodule when they need to make use of phpCAS. Now that I’ve been doing more work on phpCAS (and am more interested in keeping our applications using up-to-date versions), I’ve decided to automate the process of mirroring the Subversion repository on GitHub. Read on for details of how I’ve set this up and the scripts for keeping the mirror in sync.

On my development server I have a git repository I’ve cloned from the Jasig Subversion repository via:

git svn clone --stdlayout https://source.jasig.org/cas-clients/phpcas/

I use this repository for my phpCAS development and am continually using git svn rebase and git svn dcommit to update my branches from Subversion and commit changes back to the Subversion repository.

My goal was to fetch from Subversion and push all of the branches and tags from the Subversion repository to GitHub while ignoring any private branches or un-dcommited changes I might have kicking about my development repository.

Step 1: Add the GitHub repository as a remote

git remote add github git@github.com:adamfranco/phpcas.git

Step 2: Fetch the latest changes from the svn repository
To do this, I just needed to run git svn fetch to import commits from the Subversion repository into my Git repository.

Step 3: Make Git tags for Subversion tag-branches
I may be doing something wrong, but it seems that Subversion tags come through git svn as git branches rather than as git “tag” objects. Basically they are a branch with a single commit that just adds the tag message, but no content change. Using git show I found I could grab the parent id, message, and other metadata from the “tag-branch”, then feed that into git tag to create actual tag objects in the git repository.

Step 4: Push subversion branches and newly created tags to GitHub
When called with no parameters git push will push all branches that have matching names in both the source and the destination repository. This wasn’t going to work for me since I want to only automatically push the branch-state that exists in subversion (not any un-dcommitted changes in my Git repository) and want to create mirrors of any new branches that appear in the Subversion repository. To accomplish this I needed to specify every branch individually. I determined the list of branches via:

git branch -r | grep -v '/' | grep -v trunk

then looped through them and appended them to the hard-coded mapping between the svn “trunk” and the GitHub “master”:

$cmd = 'git push --tags github refs/remotes/trunk:refs/heads/master ';
foreach ($svnBranches as $branch) {
	$cmd .= 'refs/remotes/'.$branch.':refs/heads/'.$branch.' ';
}

All together: update_github_phpcas
Below is a script which performs the tasks above. I’ve added it to my crontab so that it runs every half-hour and keeps my GitHub repository in-sync with the Jasig Subversion repository.

I think that this script should work with very few changes for mirroring any Subversion repository as a Git repository.

Why use reverse-proxy caching?

For most public-facing web applications, the significant majority of their traffic is anonymous, non-authenticated users. Even with a variety of internal data-cache mechanisms and other good optimizations, a large amount of code execution goes into executing a PHP application to generate a page even if the content of this page will be the same for many users. Code and query optimization are very important to improving the experience for all users of a web application, but even the most basic “Hello World” script will top out at about 3k requests/second due to the overhead of Apache and PHP — many real applications top out at less than 200 requests/second. Varnish, a light-weight proxy-server that can run on the same host as the webserver, can cache pages in memory and can serve them at rates of more than 10k requests/second with thousands of concurrent connections.

While the point of web-applications is to have content be dynamic and easily changeable, for most applications and most of the anonymous users, receiving content that is slightly stale (cached for 5 minutes or something similar) isn’t a big deal. Sure, visitors to your blog might not see the latest post for a few minutes, but they will get their response in 4 milliseconds rather than 2 seconds.

Should your site get posted on Slashdot, a caching reverse-proxy server will give anonymous visitor #2 and up the same page from cache (until expiration), while authenticated users continue to have their requests passed through to the Apache/PHP back-end. Everyone wins.

Caveats

Before we get into how to set this up, you should be aware of a few caveats (in addition to increased complexity) that come with this scheme.

1. Stale Content

Ideally, pages would always be served from the cache for as long as they don’t change, then the application would expire pages when they are changed on the back-end. Varnish has an API that supports this behavior and Drupal Varnish module is being developed to do this dynamic cache-clearing for Drupal sites, but overall, dynamic cache clearing is much more difficult to set up than time-based cache expiration.

When using time-based cache expiration, the challenge is to balance the needs for content freshness (shorter cache lifetimes) against the efficiency of cache hits (longer cache lifetimes will result in more clients using the cached versions). For content that doesn’t need to be up-to-the-minute fresh, a cache lifetime of around 5 minutes might be a good starting point. If the content only changes daily at certain time, a fixed expiration time (shortly after the data sync) might be appropriate.

2. Cookie Use

If your application only uses a cookies set by PHP’s session_start() function, then lazy_sessions.php should work transparently without modification of either that include file or your application (other than including the file). If your application sets other cookies then these will cause the reverse-proxy not to cache them unless you specifically exclude them in the reverse-proxy server’s configuration.

3. Data Caching in the $_SESSION

If you use the $_SESSION array as a data cache on anonymous requests, then these anonymous requests will be given a session cookie and their requests won’t be served from the reverse-proxy’s cache. Rather than using the $_SESSION array for non-user-specific data, cache such data with APC or memcached. This also has the advantage of such non-user-specific data not having to be rebuilt for every new client.

4. flush() and output buffering

The default PHP session handling mechanism adds the session cookie to the response headers right when session_start() is called and writes the data off to the file-system after the script exits and the data has been sent. This default behavior ensures that users will always get a session cookie and saves the session data as the final processing step after all class destructors have been called.

Since we don’t want to always set a session cookie, we need to remove the Set-Cookie header before headers are sent to the client. Output buffering with ob_start() will ensure that we have a chance to decide to clear the Set-Cookie header at script shutdown.

In some cases (such as incrementally sending large binary files) we want to send the content body (and therefor also the headers) before the script exits using the flush() function. To ensure that the session cookie is properly removed session_write_close() must be called before flush() or any other code that causes headers to be sent.

Implementation

Implementing reverse-proxy caching has three steps: PHP changes to enable lazy sessions, PHP changes to set cache-controlling headers, and finally the reverse-proxy server setup. For this example I’ll use the Varnish reverse-proxy server, but others could be used instead.

1. PHP: Lazy Sessions

The first thing that needs to happen to make anonymous requests cache-able in an application that uses sessions is to ensure that sessions are only started when there is session data to be stored. By default, PHP’s session handling mechanisms add a session cookie to the response header and store a session data file on the server on page-load that calls session_start(). While this behavior makes it easy to write applications that use sessions, it effectively means that there is no way to differentiate between responses that are for a particular user and those that could be for many users.

Including the lazy_sessions.php file before session_start() is called will override the default session-handling mechanism with one that checks to see if there is any data in the $_SESSION array before sending the user a Set-Cookie header and storing a session file:

<?php

// Include files or other pre-session_start code

require_once('lazy_sessions/lazy_sessions.php');
start_session();

// The rest of the application code.
?>

If your application needs to flush content and thereby send headers before script shutdown (such as incrementally sending file data), call session_write_close() if session_start() has been called for that script:

<?php

// Include files or other pre-session_start code

require_once('lazy_sessions/lazy_sessions.php');
start_session();

// other application code.

// If session_write_close() is not called before flushing, then the Set-Cookie
// header will be sent before our custom session handler has a chance to determine
// if a session is even needed.
session_write_close();

print "Hello";
flush();
print " World.";
flush();

?>

2. PHP: Cache-Control headers

Now that we have our cookies straightened out, we need to ensure that our PHP scripts respond with HTTP headers that indicate that downstream clients such as our reverse-proxy and the user’s browser are allowed to cache anonymous pages. There are a number of different Cache-Controlling Headers that may affect whether a particular cache may store a given response. By default, PHP sets all of these headers to indicate that no caches may store any pages, ensuring that they are dynamic.

<?php

// If the session data is empty, then we could assume that there is no per-user data
// and that the response can be cached.
if (!count($_SESSION)) {

// Alternatively, we could check an application-specific value (such as a user-id)
// to determine if the response is for a particular user.
// if (!isset($_SESSION['user_id'])) {

// Cache for 5 minutes
$maxAge = 300;

header('Expires: '.gmdate('D, d M Y H:i:s', time() + $maxAge).' GMT', true);
header('Cache-Control: public, max-age='.$maxAge, true);
header('Pragma: ', true);
}

header('Vary: Cookie,Accept-Encoding', true);

The two most important headers with regard to caching with varnish are the following:

The Cache-Control header.

The Cache-Control: public, max-age=300 header indicates to any clients (such as the Varnish caching proxy) that this response can be cached in public caches valid for many downstream clients. The max-age portion of the header indicates that the cache may store this response for 300 seconds.

As I understand it (possibly wrong) Varnish only looks at the max-age portion of the Cache-Control header when determining how long to store a response. Apparently it ignores the Expires header for its cache-expiration purposes, though this header is passed on to downstream clients.

The Vary header

The Vary: Cookie,Accept-Encoding header tells Varnish (and in-browser caches) that they should not respond with the cached version of a response if the request includes a cookie or a different cookie from the request that previously had its response cached. Similarly, if one client says that it accepts gzip encoding via an Accept-Encoding: gzip request header, then the cached response may be compressed with gzip and should not be sent in response to requests from clients that do not state that they accept gzip encoding.

While Varnish’s behavior is to never cache or respond from cache when cookies are present, without the Vary: Cookie response header, browsers or other downstream caches may respond with a cached response valid for only anonymous users even though a cookie is now present.

See my notes on Cache-Controlling Headers for more details about other headers and how they affect the Varnish cache and in-browser caches.

3. Varnish (Reverse-Proxy) Configuration

The /etc/varnish/default.vcl config file controls how Varnish responds to requests and responses, in particular whether or not it should cache or not. Below is the contents of my default.vcl file.

backend default {
.host = "127.0.0.1";
.port = "80";
}

sub vcl_recv {
// Remove has_js and Google Analytics __* cookies.
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+|has_js)=[^;]*", "");
// Remove a ";" prefix, if present.
set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
// Remove empty cookies.
if (req.http.Cookie ~ "^\s*$") {
unset req.http.Cookie;
}

// Cache all requests by default, overriding the
// standard Varnish behavior.
// if (req.request == "GET" || req.request == "HEAD") {
//   return (lookup);
// }
}

sub vcl_hash {
if (req.http.Cookie) {
set req.hash += req.http.Cookie;
}
}

sub vcl_fetch {
if (!beresp.cacheable) {
	return (pass);
}

// If using PHP < 5.3 there is no way to fully delete headers, so empty
// Set-Cookie headers may be in the response. Ignore these empty headers.
if (beresp.http.Set-Cookie ~ "^\s*$") {
	unset beresp.http.Set-Cookie;
}

if (beresp.http.Set-Cookie) {
	return (pass);
}
return (deliver);
}

Single Machine Configuration

Pull out the database, use multiple web-servers

The two main components of Drupal (and most similar web applications) are the webserver, which handles PHP execution and file-serving; and the MySQL database, which stores all data with the exception of uploaded files. By putting the database on a separate machine we can can have multiple machines acting as front-end web-servers, both of them reading and writing to the same database. In this way, it doesn’t matter which web-server handles a given request as they will both get the same information out of the database. With two or more web-servers, our platform gains some redundancy since one web-server can fail while the second keeps handling requests.

With both web-servers point at the same database server, the database server still remains a single point of failure. Database clustering can alleviate this problem, but will be the subject of a future post.

Multiple web-server challenges

This redundancy does come at a cost in complexity however, since we need to ensure that any uploaded files are available on both web-servers. There seem to be two primary ways of tackling this problem (without resorting to costly and complex distributed file-system tools). The first is use rsync to copy files between the web-servers every few minutes.

Two web servers with rsync

• Files cannot be deleted in the sync as newly-added files will exist on only one web-server. Since the sync is two-way, there is no way for the rsync processes to tell the difference between a new file and a deleted file.
• Requests that come to the “other” web-server will not be able to access new files until the sync happens.
• If additional web-servers are added, the sync process needs to be updated on every existing web-server to include the new web-server

The other alternative is to store uploaded files on a separate file-server, whose upload directory is mounted on each web-server using NFS. This method eliminates the synchronization problems, since all web-servers are essentially writing to the same directory.

Two web servers with NFS

Best of both worlds

In order to better solve this problem, the approach we took is to go the NFS route, but augment it with a backup copy of the files stored on the local file-system of each web-server. Every ten minutes or so a script (sync_files.sh) runs that checks to see if the shared NFS directory is available, and if so syncs the uploaded-files to a backup location on the web-server’s file-system. This backup copy has its permissions set so that the Apache process cannot write to it, preventing synchronization problems if the shared NFS directory goes offline and we need to serve files out of the backup copy.

Two web servers with NFS and local backup copies.

An important consideration in this setup is that the NFS share is mounted in ‘soft’ mode so that file-access errors will time out quickly and allow for a timely switch-over to our backup files.

files.example.edu:/images       /mnt/files     nfs     soft    0 0

If the default ‘hard’ NFS mount is used, the check_link processes will hang indefinitely while trying to communicate with the file-server and never switch to our backup files.

Here is an example layout on the web-server to accomplish this setup:

# The scripts that will be run by cron:
/usr/local/bin/check_link.sh  # Run every minute
/usr/local/bin/sync_files.sh   # Run every 10 minutes

# The mounted NFS share:
/mnt/files/

# The backup copy of files:
/srv/files_read_only/

# The 'files' symbolic link, pointing normally at the NFS share:
/srv/files/ => /mnt/files/
# On NFS failure, this link will be switched to the backup directory:
/srv/files/ => /srv/files_read_only/

# The Drupal code directory:
/srv/drupal/
# The files directory for a site is a link into the switched files link
/srv/drupal/sites/www.example.com/files/ => /srv/files/www.example.com/files/

By mounting the shared NFS directory, keeping a read-only local copy of the files, and monitoring the state of the NFS directory we gain the following benefits:

• No problems with synchronization as all web-servers share the same remote filesystem.
• Synchronization of the local backup copies is not a problem as this is always a one-way sync rather than a two-way sync between different web-servers.
• While the NFS file-server is still a single point of failure, read access to the uploaded files (via the backup copy) will be restored after a maximum of one minute plus the NFS time-out (2 minutes by default for ‘soft’ mounts).
• The web-servers don’t need to know about each other, easing configuration if additional web-servers are added.

This configuration adds an extra machine to the platform mix and a bit of complexity, but it makes normal operation robust (instant file availability to all web-servers) and allows for graceful degradation (file-access becomes read-only) if the file-server goes down.

Many thanks to our system administrator, Mark Pyfrom, for all of his help in developing and testing this platform.

* Update on 2009-09-10: added note about ‘soft’ NFS mounts and an example file-system layout.

I wanted to export all 600+ of my tweets, so I wrote the following little php script to accomplish this. I have not yet tested it with many concurrent users or added a form to select which user to update. Until I do so, I won’t be providing it as an end-user service. You are free to put it on your own machine and use it though.

TwitterExport.php

<?php
/**
 * This script will allow the export of complete user time-lines from the twitter
 * service. It joins together all pages of status updates into one large XML block
 * that can then be reformatted/processed with other tools.
 *
 * @since 10/13/08
 *
 * @copyright Copyright © 2008, Adam Franco
 * @license http://www.gnu.org/copyleft/gpl.html GNU General Public License (GPL)
 */

$user = 'afranco_work';	// Replace this with your user name.

header('Content-type: text/plain');

$allDoc = new DOMDocument;
$root = $allDoc->appendChild($allDoc->createElement('statuses'));
$root->setAttribute('type', 'array');

$page = 1;
do {
	$numStatus = 0;

	$pageDoc = new DOMDocument;
	$res = @$pageDoc->load('http://twitter.com/statuses/user_timeline/'.$user.'.xml?page='.$page);
	if (!$res) {
		print "\n\n**** Error loading page $page ****";
		exit;
	}
	foreach ($pageDoc->getElementsByTagName('status') as $status) {
		$root->appendChild($allDoc->createTextNode("\n"));
		$root->appendChild($allDoc->importNode($status, true));
		$numStatus++;
	}

	print "\nLoaded page $page with $numStatus status updates.";
	flush();

	$page ++;
	sleep(1);

} while ($numStatus);

print "\nDone loading timeline.";
print "\n\n\n";

$root->appendChild($allDoc->createTextNode("\n"));
print $allDoc->saveXml();

Usage (assuming PHP is installed)

1. Save the code above on your machine as twitter_export.php
2. Edit the code to change the $user variable to be your own Twitter username
3. From the command line run php twitter_export.php
4. Copy/paste the XML output into a file for safe keeping and further processing

Abstract

Segue and Concerto are two curricular applications built upon Harmoni, an Open Service Interface Definition-based (OSID) service-oriented application framework. This demonstration will show how website content created in Segue is stored as OSID Assets in Harmoni’s OSID Repository. Similarly, the demonstration will show how multimedia assets created in Concerto can be stored same repository. Interoperability will be demonstrated as each application is used to view and make real-time modifications to the OSID Assets created using the other application, while at the same time respecting the authorizations given to those assets. Additionally, an OSID Repository to OAI-PMH gateway will be shown providing the LibraryFind meta-search tool with access to the metadata for content created in Segue, Concerto, and a lightweight, read-only OSID Repository.

• Companion Paper: PDF (76 KB)
• Presentation Slides: PDF (7.4 MB)

Software Demonstrated:

• Harmoni Application Framework (Middlebury College)
• Segue version 2 (Middlebury College)
• Concerto (Middlebury College)
• LibraryFind (Oregon State University)

Visitor registration brings with it a few interesting challenges. As in Segue 1, we want (and need) to be able to allow people outside of the Middlebury community to join in on public discussions hosted in Segue. As well, Middlebury users often need to give access to restricted parts of their sites to people off-campus with whom they are collaborating. Our visitor registration system therefore needs to be easy to use by registrants, keep out spammers, as well as enable searches for visitor accounts by community users.

To keep out spammers, the visitor registration form uses reCAPTCHA to try to verify that a human is sitting at the browser. There are other CAPTCHA systems out there, but I like the philosophy and approach of reCAPTCHA. Starting with words that OCR software had trouble reading seems like a good idea. After the registration form is filled out, Segue sends an email to the address entered with a unique registration code. Until the link in the email is clicked on (and hence the address verified) the account is locked.

To enable easy searching of visitor accounts, visitors are asked to enter their name. While there are a few restrictions on names, these are user-chooseble. To provide some measure of differentiation between verified institution accounts and visitor accounts visitor accounts have the user-chosen name followed by their email domain name in parenthesis, e.g.:

Adam Franco (gmail.com)

I weighed including the entire email address as that is the only verified information we have about the visitor accounts, but I’d rather not open that information up for harvesting by spammers. If abuse becomes an issue, the visitor registration system also supports both black-lists and white-lists of email domains.

I’ve now been working on Segue 2 directly or indirectly for 5 years, since June 2003. It has been a long road and it is wonderful to finally be cresting the last rise. That said, as the feature-request tracker indicates, we still have a lot to do over the next 12 weeks.

Theming
This past week I rebuilt the theming system for the 4th (and last before production) time. The challenge with the theming system is that we wanted to enable end-users to choose from a few straight-forward options for things like ‘overall color scheme’, ‘font size’, corner-treatment — not all of which mapped cleanly to CSS properties. As well, to enable more powerful themes, we needed to let theme developers wrap each content type with HTML tags in order to get some effects that are just not possible with plain CSS when the dimensions of the element are not known. Our first three theming implementations involved different PHP classes for each theme with method for setting various options. Each implementation had its own strengths and weaknesses, but they were all hideously complex and required theme developers to know PHP in order to do more than change the CSS. The new theme implementation scraps all of that complexity and defines themes as a set of CSS files and HTML templates, with associated images. An extension to this simple base adds an option listing (defined in XML) that enables placeholders in the CSS and HTML templates to be replaced with values from end-user-choose-able options.

With the new theming system in place in development Alex has set to work building the first three (Rounded Corners, Shadow Box, and Tabs) of the themes that will be distributed with Segue while I’ve been finishing up the user-interfaces for choosing theme options and enabling more advanced users to customize the theme CSS and HTML in their web-browser. So far Alex and I are pretty happy with the new theming system and its simplicity should give it much longer legs than our previous attempts.

While it won’t make it to production, I eventually plan to have a theme-gallery that users can choose to publish their designs to for use by the rest of the community.

Up Next
With theming out of the way the following are some of the next areas I’ll be working on in addition to fixing bugs and working out smaller kinks:

• Templates – starting points for sites
• Enabling embedded videos from trusted sites (i.e. YouTube, Vimeo, etc)
• Visitor Registration
• Copy/Move tools for Classic Mode
• Display of RSS feeds

Still a lot to do, but with each addition Segue 2 gets much closer to being able to take over as the primary course website system.

I wrote this script because I have been recently making heavy use of Miro (formerly known as “The Democracy Player“) to download videos from YouTube in order to watch them off-line. Miro also provides a nice UI for aggregating videos and remembers my spot when I go back to watching later (nice for long documentaries). Miro however, expects links to videos in RSS enclosure tags, something that WordPress (and probably other blogging software) doesn’t do for embeded videos.

Throw Away Your Telescreen is a video blog done by one of my favorite geo-political bloggers, Dave on Fire, and a few others. In it they link out to the most interesting “documentaries, lectures, and interviews that follow a different editorial line” from the corporate press. I highly recommend all of the videos on it that I have seen.

Throw Away Your Telescreen has all the makings of an indie-news channel, perfect for Miro which was developed to encourage participatory media and culture. The only thing missing was to get the videos embedded in Throw Away Your Telescreen’s posts in such a way that Miro can find them. With the WPEnclosureAdder, this has now been done. Use this feed to view Throw Away Your Telescreen in Miro.

• View the source-code of the latest version. (save-as to download)
• License: GNU General Public License (GPL) version 3 or later
• Requirements (for hosting it yourself): PHP version 5.2 or later
• Git Repository: http://www2.adamfranco.com/WPEnclosureAdder.git

I wrote this script with Throw Away Your Telescreen in mind, but it should work with any other WordPress blog, and probably with RSS feeds generated from other blogging tools. To point it at another blog’s RSS feed, enter the feed url in the form below:

Using my version will use my default search strings for YouTube and GoogleVideo videos. If you would like to change what is being searched for, please download the script, change the configuration, and host it on your own website. I have licensed the WPEnclosureAdder under the GNU General Public License (GPL) version 3 or later, so you are free to copy and modify this script as per the terms of that license.

To accomplish this task, I have written a new script, the KML Joiner that will combine any KML documents on the web together into a single (referenced) KML document. (try it out)

More Detail: for those interested in KML
The resulting document is a collection of network links, each of which points to one of the KML URLs specified. Doing this rather than combining their text together into a static KML document prevents style collisions as well as allows changes in the source data to propagate to the combined document.

Refresh intervals can optionally be specified for every source document allowing for a server-friendly combination of static data with rapidly changing data. By default, no refresh interval is specified, making the linked documents load only once when first accessed.

Example:

View the KML Joiner with fields filled in that generates the map below.

View Larger Map

The map above is of the trip mentioned in a previous blog post, but this time the data sources (1. a static KML file with the path and house placemark, 2. a dynamic KML document generated with my Photo set to KML script) joined together with the KML Joiner script instead of manually put together with a text editor.

Usage:
You are welcome to use this script hosted on my site, or you can download it and run it on your own computer/webserver.

This script is available under the GNU General Public License (GPL) version 3 or later. (Source Code)

Please post any suggestions for fixes or changes. Thanks!

To fill this niche, I present a small script I wrote to generate a KML file from the geotagged photos in a set:

Features:

• Generate a KML file from a Flickr photo set
• Directly open the KML file in Google Maps
• Choose what size image to include in the placemark description for each photo.
• Optionaly draw a path (line) from photo to photo ordered in one of several ways: by date taken, by date uploaded, by set order. Useful for making a quick and dirty map of a trip.

Examples:

• KML / GoogleMaps – Some photos from Cape Cod.
  
  View Larger Map
   
• KML / GoogleMaps – A set of photos from a trip I took around Turkey, with lines drawn chronologically. Since this is a large set that causes GoogleMaps to time-out, I’ve downloaded the KML file and then re-uploaded it to my website. This is the method I recommend for large photo sets.
  
  View Larger Map
   

You are welcome to use this script hosted on my site, or you can download it and run it on your own computer/webserver. If you would like to run it yourself, please be aware of the following…

System Requirements:

• PHP 5.2 or greater.
• The PEAR Flickr API

This script is available under the GNU General Public License (GPL) version 3 or later. (Source Code)

Updates::

• 2011-10-06
  • Moved the source-code to Github
• 2007-08-27
  • Now uses htmlspecialchars() to clean titles instead of htmlentities(), the latter of which was causing excessive translation of German characters. Thanks Stefan Geens, for pointing this out.
  • Form now generates valid XHTML 1.0 strict.
  • Now can use image thumbnails instead of camera icons. Thanks for the idea Nicolas Hoizey.
• 2007-08-24
  • Now escapes ampersands in titles and descriptions. Thanks Jesse for pointing this out.

  Future Improvement Ideas::

  • Add an option for icon size.
  • Add options for custom icon/path styles. I’m not sure whether to give several options, or just provide a field for a block of arbitrary KML style-markup.
  ]]> http://www.adamfranco.com/2007/08/23/flickr-photo-set-to-kml/feed/ 45