Installing and Running WIBS – Last Updated: July 7, 2002 by Art Rhyno <>

WIBS (Windsor Internet Booking System) currently requires Apache , MySQL , and PHP . There is good documentation on how to get these applications running on each of their web sites, and this guide assumes that these systems are already in place. You may also have access to some of these programs at your library without going through the installation yourself, Apache is the most popular web server in the world, and MySQL/PHP are a very common duo for serving dynamic web pages. This current release will be the last one that uses PHP and the next version will use Java and Tomcat .  MySQL will still be an option for the back end but the calendar logic will be supplied by a calendar server called UW Calendar , with an option to plug in another calendar server like the one shipped with iPlanet/ONE .

It is possible to substitute different options for these even in this release, for example using PHP with IIS, but the Apache/MySQL/PHP combination is so hard to beat for performance that it is hard to imagine using a different setup. WIBS is based closely on MRBS (Meeting Room Booking System) written by Daniel Gardner, which in turn, borrows from David Wilkinson’s calendar functions . This is one of the many joys of Open Source software, it can find itself in all sorts of neat combinations.

In addition to Apache, MySQL, and PHP, you will need: You should also be able to modify the registry and create file associations on your client machines if using Windows on the stations to be booked.

Setting Up the Server

1.    When you have the Apache software in place, unzip or untar the WIBS distribution off the HTML root for Apache. The wibs directory will have subdirectories called admin, client and local . You will probably want to use Apache's .htaccess file to limit access to these directories, in which case, be aware that by default web directories are usually wide open in Apache. There is quite good documentation on adding authentication at  <> in addition to the Apache site itself. Follow the instructions in the readme.txt file to finish the server-side installation.

2. When you see the stations in your browser, explore the examples in the local/template subdirectory to see if one meets your needs.

3. The admin screens are quite simple. The only that tends to cause confusion is the purge option, which produces a screen like this:
Screenshot of Purge Entries

In this case, it is simple a matter of clicking on the date to the right that you want entries purged for. WIBS will wipe out booking information up to and including the date selected.

Setting Up Client Machines (Windows)

1.    To set up a machine for booking, it is necessary to copy the contents of  wibs/client from the server to a directory called WIBS on the local disk. We will add a few entries to the File Types supported by Windows using these programs.  These can be set in Windows Explorer under Folder Options as shown:

Screenshot of Explorer
You should see a list of all types supported by the system.

Screenshot of File Types  

2.    We will add four to the list (.wox,.way ,.min,.wib). Click on the Advanced button and create a new extension as shown.

Screenshot of extensions dialog
3.    Now click on Advanced again and be sure to uncheck the option for Confirm open after download.

Screenshot of Options

4.    Click on New and associate the extension with the appropriate program in the wibs directory (wox -> \wibs\restart.exe , way -> \wibs\wibsact.exe, min -> \wibs\wibsmin.exe , wib -> \wibs\wibschk.exe).

Screenshot of Assoc. Program Example

The wibschk.exe program uses an INI file (\wibs\wibschk.ini - sorry this directory is hardcoded for now). The "login" entry in this file has to reflect the first letter of the machine name (see below). So if the machine is "WORKSTS1", then the entry should be:

    login=WIBS Patron Logon - W

where "W" reflects the first letter of "WORKST1". Note that if the machines have a name that starts with “M”, wibschk will get the window mixed up with the background browser window (since it appears as “WIBS Patron Logon - Microsoft Internet Explorer” in the window list).

Go through the icons and stick the c:\wibs\wibsgo.exe program in front of the executable specified as shown. The directory information may need to be translated to short filenames if more than 8 characters.

Shortcut Example
5. Finally, you will need to add an entry to the registry to bring up the logon automatically BUT TEST OUT THE PROGRAM ON THE COMMAND LINE FIRST! You can get yourself in a loop if any of the associations or the program gets misaligned. Run the wibsstart program with the parameters shown below, and then go through a regular login to test out the associations. When it looks ok, the registry key to make it happen on every startup is documented at:

Entries need to be of the form:

“c:\wibs\wibsstart.exe” browser url machine timelimit

where browser is the path and executable for the browser, typically “c:\progra~1\intern~1\iexplore.exe”. Put the url for WIBS specifying the complete path for logon, e.g.

Give the machine name, i.e., the identifier used in the IP section of the admin screen, e.g. WORKST1. Note that THERE IS A SPACE BETWEEN THE URL AND MACHINE NAME. Give a timelimit of about 20 (this is the number of seconds to wait for the window name to show up) so that if someone does manage to thwart the browser, they won’t get very far.

Hide the Programs folder (if not using special security software) on the Start button and restart the machine. That’s it!

Some Common Questions

1. Why use helper applications for controlling the desktop?
Originally, WIBS was set up with a windows-based client program and replaced the windows shell to provide security. However, it turned out to be a maintenance nightmare to make a change and required ODBC drivers for MySQL on each desktop. The browser approach allows a multi-platform approach. Define helper applications as appropriate for your platform and run the appropriate browser. Plus, writing security software for windows is not for the faint of heart.
2. Why don’t you use the 3M Selfcheck Protocol?
We use SQL to talk to the patron tables in our library system so it wasn’t necessary to set this up. One of the issues with 3M and presumably, NCIP, is that most library vendors charge a fee for its use. But if someone was to provide some documentation on 3M, it is possible that this interface could be written in PHP. However, this is currently going to be implemented as part of the port to Java.
3. How does WIBS compare to commercial options for booking workstations?
At the time WIBS was put together, we had no budget for a commercial system and didn’t look too closely at the options. If you are comfortable with tinkering with PHP, you can probably extend WIBS if desired and handle almost any issue that might arise. If your organization requires that you have 24/7 support for any piece of software you acquire, then WIBS may not be the option to pursue. WIBS has done many thousands of bookings at two sites for almost a year, but there are still features being added and time-based applications are notorious for producing weird intersections of events that don’t always get flushed out very quickly. A pilot project may be a good way to see if WIBS meets your needs.
4. How can I customize the screens in WIBS?
You can work with the colors by modifying the wibs.css file. The input boxes and some site specific information is defined in the local directory. You can associate different icons with different stations as they are defined. Otherwise, you may have to dive into the PHP code.
5. What are the future plans for WIBS?
These are still evolving. Some of the ideas that may be implemented in the short term are:
Functions that have been requested/suggested include:
Major changes in the pipeline:
6. Why port everything to Java and use a Calendar server?
A few years ago I started working on an Open Source ILS called PYTHEAS and I started out with much the same building blocks as WIBS, especially in terms of PHP and MySQL. I migrated all the pieces of PYTHEAS to Java because the APIs are richer and I have far more expertise with XML in Java than I do with PHP (or anything else). WIBS is sort of following the same path. I could hack PHP to add additional functions, but I can set up a framework with Java where these pieces can be plugged in and originate from anywhere. This approach is possible with PHP, but it would require a radical reworking of the existing code.
The advantages of Java and the Calendar server may be best demonstrated by an example. Some of the students who prebook our stations in advance would like an option to download this into their local calendar systems. The closest standard for sharing this kind of information is iCalendar. To add iCalendar support to WIBS would require a lot of rewriting and oodles of logic that isn’t already there. Pulling this format out of a calendar server is trivial. Adding a function like repeat bookings is another example, it could be hacked in but the logic is already in a calendar server.
The other driving factor is a deep desire to share a common code base between PYTHEAS and WIBS, using the same tools for both makes it infinitely easier to jump between them.
WIBS works well for us, but we encourage deviations from what we have assembled and any changes that we add. Just remember to share you versions with others, if it takes a village to raise a child, it takes a virtual community to foster an Open Source application.

Return to main page

Hosted by the amazing folks at:
SourceForge Logo