CS 1102 Lab 6: The State of the Web

Lab Motivation and Goals

This lab looks at the Orbitz web program bug (from Tuesday's class) and general issues with programming with state on the web.

As a reminder (or for those who missed class on Tuesday), here are the steps that showed the bug:

  1. The user searched for hotels in a given city, then viewed the details for hotel1 in a new window (leaving the search window open).
  2. The user viewed the details for hotel2 in a new window (leaving the search window and hotel1 detail windows open).
  3. The user switched back to the hotel1 details window and clicked on the button to reserve at hotel1.
  4. The user received confirmation of a reservation at hotel2.

Exercises

Download the starter file for lab. In it, you'll find data definitions, an example database of hotel data, and some printing routines for displaying hotel data. You'll also find several text-gui versions of an Orbitz mockup, which we'll use in the following exercises.

Some of the exercises ask you to explain your answers. Take this part seriously and write your reasons down in your solutions file for lab (just put the answers in a block comment). Being able to give technical arguments precisely is one of the skills this lab tries to practice, and we will read your answers.

  1. Version 1 follows the set!-free style we've used in class all term. Run that version to familiarize yourself with the prompts and interface. When the program prompts you for which hotel to view, just enter the number labeling the hotel. Use any single number for a date when you reserve a hotel.

  2. In a fit of withdrawal from assignment statements, Billie Lovesbitz rewrites version 1 as version 2 (resulting in some hideously ugly Scheme code, but we'll ignore that for now). Run version 2 and either produce an interaction (sequence of inputs to the function) that gives a different result than the same inputs to version 1 or justify (in writing) that no such input sequence exists.

  3. Billie decides to release version 2 as a web program, which requires breaking the code into functions for different scripts and adding "submit" functions, as we did in class. Study the result (version 3) and run it. Can you reproduce the Orbitz bug? Either give a sequence of steps to do it or try to explain (in writing) why the Orbitz bug can't show up with this code.

  4. Version 3 doesn't really simulate the Orbitz scenario because there the user switched between pages in different windows, and version 3 doesn't give a way to do that. We can simulate different pages in different windows by modifying the scripts (resulting in version 4) to return the pages (functions) rather than calling them automatically. We can simulate pressing the submit buttons by giving names to the results of calling each page, then calling these functions/pages in turn. For example: 

    (define mp (hotel-main-page4))
(define choosehilton (mp 1))
...

    Reproduce the Orbitz bug in version 4 by writing down a sequence of Scheme expressions that reveal the bug. What features of version 4 made the bug possible?

  5. Copy version 1 (the set!-free original) to create version 5 that has scripts with multiple pages accessible (similar in spirit to version 4) but without set!. Test version 5 to make sure it produces similar interactions to version 1. Can you reproduce the bug from version 4 in version 5? Either show steps that yield the bug or explain why the bug doesn't occur with version 5.

    In your edits, be sure to rename the recursive call to main-hotel-page1 in the inner cond where reserve-for equals no.

  6. Travelers often have multiple active reservations for different dates. Extend a copy of version 1 to yield version 6 (just as normal scheme code, not yet as scripts), which tracks all of the user's current reservations. Version 6 should have the following features:
    1. It print out a list of all the reservations the user has made before prompting them to view hotels (on the "main page").
    2. Whenever the user makes a reservation, the new reservation should show up in the list the next time the user gets the view hotel prompt (not at some later time).
    3. Even if the user makes a reservation, they should get the view hotel prompt afterwards (as opposed to the program terminating, as version 1 does).
    Edit the version 1 copy as you see fit. Don't worry about the format of the printed list (something like (printf "~a~n" thelist) is fine). Don't worry about letting the user delete reservations or about resetting the list contents with each new execution from interactions window (though it's fine to reset if you wish). Both of these issues are besides the point of this exercise.

    Everybody should be able to finish up to this point

  7. Convert a copy of version 6 to work as web scripts with multiple active windows (as with version 4).

  8. Ideally (from a utility perspective), all pages should see reservations made in all other pages. For example, if a user has windows open to view each of hotel1 and hotel2, and makes a reservation in the hotel1 page, the "main page" reached from the hotel2 page should show the hotel1 reservation. Does your version have this behavior? Either write the sequence demonstrating this or explain why it does not.

    If your version does not have this behavior (and you have time), try making another version that does have this behavior. If you are short on time, do to the next question first

  9. What lessons can you draw about web programming and state (meaning variables and set!) from these exercises?

Back to the labs page