Setting up URL builder & Webcache

Introduction

Bedework ships with a production-ready page caching application for caching public event data feeds.  Webcache is used only for data feeds and is fronted by the URL builder, a feed URL and widget generator.  Webcache itself fronts Bedework, storing results pages in memory and, if necessary, a file hierarchy.   Result pages may appear in a variety of formats (xml, json, ics, rss, html) and may contain a single event or a list of events.

Using the Webcache is recommend for two reasons.   Like any caching system, it should improve responsiveness.   Also, Webcache should protect your Bedework server from having to work so hard, which may lead to greater reliability.  Webcache can be placed on another host to further protect your Bedework server

To illustrate how Webcache works in the quickstart (where it is installed next to the rest of Bedework).  Let's say you'd like a json feed of the next 21 days of all public events.  

You'd send this URL:  http://calendar.myschool.edu/webcachev/1.0/genFeedList/21/list-json/all/all.    (Don't worry about having to actually construct such a URL.  That's what the URL Builder is for).

First Page Cache looks at the file location <topOfPageCache>/v1.0/genFeedList/21/list-json/all/all.json.  If it finds a page there, it serves it up.  Otherwise, it “translates” the URL into http://calendar.myschool.edu/feeder/listEvents.do?skinName=list-json&days=21, calls it, and then both caches the results and returns them to the user.  

Note: Prior to Bedework version 3.9.0.15, cache expiration must be managed using a script (or other mechanism) that you create.  For more details, see the Bedework wiki: http://www.bedework.org/trac/bedework/wiki/CachedFeeder/ExpiringEvents .  As of Bedework 3.9.0.15, cache entries expire after one hour, and the cache is cleared on a server restart.  For details of the webcache update in 3.9.0.15 please read the announcement.

Configuring the URL and Widget Builder

The url builder is a web form that generates feed URLs and widgets for use on other web pages.  Users specify whether they'd like a feed or a widget (paste-able code), what kind of output they're interested in, and other options.   Users may filter by categories and/or by a group.

The feed URL's may be XML, RSS, HTML, JSON, or ICS.

The widgets are javascript functions that process a JSON feed. 

Point URL Builder at Webcache

1. cd <qs>/cachedfeeder/URLandWidgetBuilder/javascript/bedework
2. edit listEvents.js and update calendarServer (line 25)
3. edit builder.js and update urlPrefix (line 21)

Reploy the urlbuilder:

./bw -deployurlbuilder

The URL Builder will be deployed to <qs>jboss-5.1.0.GA/server/default/ROOT.war/urlbuilder

If you move the Webcache

The webcache application shipped with the quickstart should work as is, out of the box.  You should not need to modify the application.  If you move the application to another server, you will need to point the webcache at your Bedework server (because the path will no longer be server-relative).

Point Webcache at Bedework

Easier way: Edit the deployed application

1. cd <qs>jboss-5.1.0.GA/server/default/bwdeploy/webcache.war
2. Explode the archive, if necessary, using the jar command.  If you replace the archive with the exploded war you can leave it that way.  Make sure the directory is called webcache.war
3. cd WEB-INF/config/environments/development.rb
4. Edit the TARGET server
5. (optionally) Jar up the directory and overwrite the old webcache.war archive.

Hard way: Rebuild webcache

This way is more work because you need to install the jruby environment.  You'll need to install jruby, warbler, and jruby-openssl. These commands should do the trick on those flavors of linux that have apt-get. sudo jruby -s gem install warbler sudo jruby -s gem install jruby-openssl

sudo apt-get install jruby
export PATH=$PATH:$JRUBY_HOME/bin
sudo jruby -s gem install warbler
sudo jruby -s gem install jruby-openssl

Then you can rebuild and redeploy with

./bw -buildwebcache
./bw -deploywebcache