Installing and Running WIBS – Last Updated: July 7,
2002 by Art Rhyno <arhyno@uwindsor.ca>
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:
- A userid/password in MySQL
- A directory with read/write access for serving
web files under Apache
- The WIBS files themselves!
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 <http://www.apacheweek.com/features/userauth>
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:
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:
You should see a list of all types supported by the system.
2. We will add four to the list (.wox,.way
,.min,.wib). Click on the Advanced button and create
a new extension as shown.
3. Now click on Advanced again and be sure to uncheck
the option for Confirm open after download.
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).
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.
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:
http://www.winguides.com/registry/display.php/109/
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.
http://thehost.here.lib/wibs/wibslogon.php?MACHINE=
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:
- defining helper applications in AppleScript for the
Macintosh platform, and setting up an option for the LTSP project
- setting up a “grouping” mechanism so that every station
is not listed on the main screen
- providing an option to “rebook” a station if it has
not been pre-booked by someone else without being knocked off the station
Functions that have been requested/suggested include:
- providing a mechanism for “bumping” a patron off
a machine remotely
- issuing random userids, passwords instead of hooking
into the library system patron database
- using LiveConnect to feed information back through
a socket to the server about a session
Major changes in the pipeline:
- changing the underpinnings from MySQL/PHP to java
and a true calendar server
- incorporating a SIP module
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:
