CSC 290A, Spring 2009: Homework

The following page lists the homework, written or programming assignments, for the Spring 2009 class. The homework is listed by due-date order : newest should be on top.


  • Submit your example and solution code through the CS department wiki by creating a new page or a set of new pages. Make them changable by only you and viewable by you, KonstantinosMenychtas, and ChenDing.
  • We have collected a set of easy to follow hints/guidelines on the Wiki-related hints page, including page creation, basic formatting, and access control.

Team Project: Instant Messaging Sever for Browser Clients. NEW

Stage 1: Basic server

In this project, you will work in a group to develop an instant-messaging server. The basic server accepts HTTP requests to establish client accounts and passwords, maintain on-line status, organize pairwise and group communication, and store message history.

The client can be any Internet browser program such as Firefox or IE. Let's say that an interested user learned about your server and its URL through you, a link on some web page, or your advertisement on campus. The functionalities of the server are organized in several basic page views. First, the user comes to the front page of the server, which allows a new user to register and an existing user to log in. You may use clear text to transfer and store user passwords, but we strongly recommend you use the encryption support of HTTP.

Once logged in, the user moves to the function page, which has choices for the user to connect to another user (bipartite chat) or to create and join a group chat (room). A bipartite chat is possible only if the other user is signed in at the same time. A chat session starts when a bipartite chat or room is established and ends when there are no more users participating in it.

For every room or bipartite chat, message history is maintained throughout the session's lifetime. The user who starts the session (bipartite chat / room) is allowed to enable one of the following choices:

  • Public history: allow everyone to see this session's history; users can see messages posted from the beginning of the session even without entering the room.
  • Private history: allow only users who have entered the room / bipartite chat to view all previous messages of the session, and nobody else.
  • No history: the users who enter the room, and only them, have recollection of messages that were posted after they entered the room
When a user leaves a session, they could be prompted to be sent a transcript to their e-mail address. When the session ends (all users leave), the server can discard the session history.

Once connected, the server creates the chat page, on which messages are displayed and updated.

For interoperability, your server should use the relevant Jabber message protocol, which is in XML format.

The project is evaluated at the weekly report for 15 min per team each Tuesday during class. The report has two parts. The first is a slide presentation of the progress in the last week and the plan for the next week. It includes progress made not just in system implementation but equally importantly system design and user demand/feedback analysis. You will use the software development process known as agile development---chiefly rapid prototyping and iterative improvements. The second part of the report is your system, or if the system is not yet developed, a demonstration of some features of your design.

The length of stage 1 is about three weeks starting from Friday March 27 and ending April 14, with three in-class presentations on March 31, April 7, and April 14.

Stage 2: Extensible server

Depending on the available time and the progress and discussion of stage 1, we will extend the design of the basic server to allow a user to add and distribute new functionalities. We will post the design requirements in the next week.

For resources, see class slides and references especially on the following subjects:

  • HTTP/CGI/Web 2.0 programming, class schedule table Feb. 19, 23, and 25.
  • Source-code control through subversion, class schedule table Feb. 12.
  • Useful Ruby libraries such as XML parsing, class schedule Mar. 3.

Homework 2: On-line email drop-box.

Have you ever found yourself in the uncomfortable situation to have to give your e-mail to people you wouldn't really want to? What if you wrote this short and easy script they could use by visiting your website to mail you instead? All you need to do use Ruby + CGI to handle an HTML form and take care of the e-mail forwarding. Your drop-box can also add keywords to the subject line, which can be used by your mailbox to classify emails based on the drop-box.

In this pre-assignment you need to implement that exact form that would serve as an "email drop-box" for your website. Yes, that is a potential source of spam, so as soon as you finish familiarizing yourself with Ruby + CGI ( Common Gateway Interface ), you are free (but not required) to elaborate on the assignment and improve your service (ex. add sessions, or some visual authentication mechanism) , or re-implement the same scenario using another language (ex. PHP + CGI) and contrast.

How to start:

  • Login to your betaweb account.
  • Visit /var/www/html/cs290 and create your own directory, using your login name. That is where you will place your scripts.
  • To be a web service, your script has to be readable and executable by everyone. However, we request that students do not look at each other's script until the deadline passes.
  • Your scripts need to have a .cgi suffix.

Other notes

  • Implement a single script to handle every possible input / context to be displayed (both the form and "sent confirmation")
  • Use Ruby 's CGI class
  • Use the Ruby's system to invoke mail (unless you have a better idea)
  • Remember you can access the get/post of the form data through the params hash of the cgi object
  • See The Ruby Way, Chapter 19 for a first set of hints. And then, the web !

This assignment is meant as a warm-up for the more feature-rich Homework 3.

Homework 2 pre-assignment is due midnight, Sunday Feb. 15th.

Homework 1: Extensible Design

A common software problem is to develop a set of tools operating on a collection of data. The goal of extensible design is to structure the system so that new tools and new data types can be added without changing the code for existing tools and data types.

In this assignment, you are asked to come up with an example programming problem and demonstrate an extensible design on the example problem. The specific requirements are

  • the problem should involve data with recursive data types
  • the existing solution should have at least one data type and one tool
  • the extension should include at least one new data type and one new tool

The design will be evaluated not only in terms of correctness but also the brevity and clarity of your program. You are encouraged to use this exercise as a way to evaluate the object-oriented features of your favorite programming language and compare it with newer alternatives especially the one we discussed in class, Ruby.

Homework 1 is due midnight, Sunday Feb. 1st.

Edit | Attach | Watch | Print version | History: r20 < r19 < r18 < r17 < r16 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r17 - 2009-03-27 - KonstantinosMenychtas
  • Edit
  • Attach
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding URCS? Send feedback