Current tasks

After today's class, it appears we're almost ready to move onward. Here is the breakdown of the system into tasks for each team:

Team 1: You're working on developing and testing a templated AVL tree. This will be used to make a tree of pointers to Tags and a tree of pointers to URLs, both ordered by TimeStamp. You'll need to implement "dummy" Tag and URL classes to test your tree. You'll also need to implement a TimeStamp class (or the like) as a wrapper around the time_t type returned by the time() function (defined in <ctime>).

Team 2: You'll be developing a red/black tree of pointers to tags, ordered by tag string. Mike Martin may choose to hand off the maintenance of the documentation to you.

Team 3: You're working on the core server code. Your code talks to the server network layer being developed by team 4. It gets URL and Tag information, and creates new objects if they don't already exist. It inserts the new objects into the trees and hash tables and creates links between URLs and Tags.

Team 4: You're working on the server network layer and a hash table. The network layer talks to the CGI programs. The hash table is a hash table of pointers to URLs; you need to implement a hash function as a method of the URL class that computes a hash value for a URL from the "link" string itself. Suggested signature: unsigned long URL::getHash(void) const; Note that this method should output the hash value before applying the "mod tablesize" operation (since, of course, the URL doesn't know how large the hash table is).

Note that there are a number of interfaces between groups here. While it is fun to write code, it is essential that you develop complete and precise specifications for your components' interfaces before you implement them. By this I mean the public members of your classes, plus the network communication protocols. From reading the above, you'll already see some things that need to be added to the URL and Tag interfaces. Please note that data members should not be public; use accessors and mutators (get and set methods) instead. Make sure you get agreement from other teams on your interface, to make sure that what you're providing matches what is needed. If you try to implement something before doing all of this, I can almost guarantee that you'll need to re-implement it.

Also, make sure you think of testing up front. This may require you to write dummy classes, driver programs, etc. It's good to develop the testing code in tandem with the "real" code, and test incrementally as you progress.