Clients not always being kicked off before scheduled reservations.

Signup Clients with all 3 reservation modes are acting in an odd fashion. They are not always allowing 'short' reservations. For example, if a pc is reserved for 4pm, it may display 'waiting for x' at 3.30. It should show that it is available for 30 minutes.

This is an expected result of an issue associated with using all three Reservation modes together (which while it sounds like a good idea, is not always ideal in practice). This problem we referred to as 'bubbles in the queue' or 'bubbling' (where a queue has to fit around a hard reservation time). It is quite a tricky problem and we spent a lot of time trying to find a suitable way to handle it given all the other requirements for the product. Following are the details of our considerations around this issue:

We had to try to figure out how to deal with the fact that when a scheduled reservation exists, the time available on that machine will eventually be less than that of a normal session (eg the normal duration for a PC is 1 hour, but there is now only 30 minutes available on that machine) and that because we don't know when a queued reservation is actually going to start (because it depends on when the most recent user logs off), it could wind up being assigned to a machine which may only have, say, 10 minutes left before the next scheduled reservation is due to start on it.

We thought that most users wouldn't want to be assigned only 10 minutes when the standard duration was 60 minutes. And we thought it could become extremely complicated to try to offer shorter durations to customers for queued reservations - do we show on the Queue Station 'user A, a machine is available now for 10 minutes if you want it' - and then how would we get them to tell us they wanted to wait for a 60 minute machine. And if the first patron in the queue doesn't want that shorter duration machine, do we offer it to the next user, and how do we do that, and so on. We thought that in a situation where there is no queue and PCs were available for shorter Immediate reservations (say 45 minutes), then users would walk up to those and start using them directly for the shorter period rather than adding themselves to the queue. If, on the hand, they wanted to have a computer for a full 60 minutes, then they would have to add themselves to a queue. Once a user is added to the queue, this indicates that they want a full 60 minute duration and that the machines with less time are not suitable for that, so the machines go into a 'pre-reserved state'. Pre-reserved means they are waiting for 'x' (scheduled reservation user) to log on. 'x' can log on early if they are there early. (It was expected that scheduled reservation users would probably turn up a few minutes early to be sure they were there when their reservation started, so scheduled reservation users can log on early if they arrive early. Their reservation will be moved forward if they log on early - it won't give them a longer duration.) You can recognise a pre-reserved state by the fact that there is no Unclaimed Session Timeout counting down on the screen. This count down will start showing on the screen once the clock hits the official start time of the session.

There were two main requirements for the system: that it be simple to understand and use, and that it be fair. The reasoning for the pre-reserved state was that queue-jumping was an issue - the system needs to ensure that those that ask for a PC first, get one first. If a queue already exists and a user logs off a machine which does not have a full duration available before the next scheduled reservation is due to start, then it did not seem fair to allow a user who has just walked in off the street to walk up and use the shorter duration PC (as an Immediate reservation) ahead of people who have been waiting in the queue (and, as mentioned, offering a short duration to a patron waiting in the queue could be too compl