Winter Quarter 1996 January 28, 1996
Document Author:
Project Sponsor:
| Yakko Wakko and Dot Profile Team:
Manager: Harry Marlin |
Yakko Wakko and Dot Profile (YWD Profile) project team is a subgroup of the Java as Desktop project. Our project is focused on building a Java calendar browser applet. The College of Computing currently uses two calendar programs: Now Up-to-Date and the X utility "plan". The Now Up-to-Date application runs on MacIntosh platform while the "plan" utility runs on Unix workstations. People with accounts in the College of Computing have the option to create a publicly readable calendar file. Our Java calendar applet must be able to read and display the information in the calendar file, allow updates to the calendar from Java, and be able to browse other people's calendar and schedule appointments.
There are several precursor systems that attempts to do the same tasks. This project team will study these other works to gain insight on the inner-working and pros and cons of the system. By studying the existing systems we will be able to create a new system that is an improvement from the existing ones. The precursor systems to be studied are: Netscape Calendar, DISCS, and previous Java Prototypes.
The Netscape Calendar was created by a College of Computing undergraduate. The application uses Hypertext Markup Language along with Perl to produce a browse-able calendar on Netscape. DISCS is a continuing project as part of the Real-World Lab (CS 4310/1/2) that implements a calendar system for the Office of Information Technology (OIT). Several College of Computing graduates have done initial Java prototypes for an edit-able calendar.
Many of the previous systems that we are going to study are written in HTML. The limited functions in HTML places many constraints on what the system can provide. Building a calendar program with Java applets provides us with more functionality and options. With the more powerful Java applet, the new calendar will be a vast improvement from previous systems.
We have discovered that a College of Computing graduate student named Anind Dey is also working on a similiar project. With Dr. Abowd's approval, Anind has joined our group and will work as the third programmer for this project. Anind joins our group at the beginning of the project. He will be included in our training sessions. By starting together at the beginning, Anind will be a great asset to our team.
The user should be able to view their schedule by hours where their appointments are displayed next to the hour that it is taking place. For example, if someone has a ten o'clock cs3302 class, the YWD dayplanner should display the class name and location beside the 10 o'clock slot.
The user should be able to view their schedule in an week-by-week fashion where summary of the daily appointments are display for the day slots within the week. For example, when the student who have four classes on Monday views the weekly display, all the classes that are on monday should be displayed. If the user wishes to view the exact time when the classes take place, he or she can click on the slot and enter the daily viewing mode.
The user should be able to view the days in the month. There will be no information displayed in the monthly view; however, the user can easily go into the daily view by clicking on a date.
The user will be able to view the past or future years. This is used if someone wishes to schedule to the future years or view the appointments for past years.
The user should be able to select a date and add an appointment for a specific time.
The user should be able to select a range of dates and add an appointment that applies to all those dates. For example, a student who have cs3302 at 10 a.m. on Monday, Wednesday, and Friday should be able to select M, W, F for the next ten weeks and schedule 10 a.m. for attending classes.
The user should be able to add a list of dates that are always the same every year. For example, a user should be able to add a list of birthdays that are automatically updated every year.
The user will be able to overlay multiple schedules and view a list of time slots that are available for everyone. The overlay display can also count the number of conflicts and show the user the time slot that have the least number of conflicts.
The YWD dayplanner should be compatible with the X window utility - "plan". The "plan" program creates a .dayplan file that is publically readable. The program should be able to read and display information stored in the .dayplan file.
The YWD dayplanner should be able to write to the .dayplan file in the same format as the ones created by the "plan" program.
If the .dayplan file does not exist, the YWD dayplanner should be able to create a new .dayplan file for the user.
The system should return the YWD dayplanner when the user requests it in a reasonable amount of time. Currently, we leave such task to the browsers. The browsers have a set amount of time before the request times out. That is the time we are going to go by unless faster response is needed.
The YWD dayplanner will get the day/month/year information from the server system. The system need to return a correct information. The YWD dayplanner will have mechanism to detect day/month/year that are out of range; however, it does not have a clocking mechanism. It depends solely on the clocking mechanism of the server.
The Java applets are independent of platforms; therefore, user can use any platform to run their YWD dayplanner as long as they satisfy the network environment.
The HotJava browser is not widely distributed yet. Many users are simply updating the popular Netscape 1.12 to Netscape 2.0. The applets are considered "untrusted program running on trusted environment." Netscape's security management does not allow the "untrusted program" to write to the client machine. This presents a problem for us when we need to store the dayplanner information to the user's machine.
Currently, we discussed three solutions:
The purpose of the applets is to move away from the use of the cgi-bin. We are going to avoid using the cgi-bin and move toward socket communication. Until the Netscape security manager changes, this is the major risk we have to deal with.
Top | Plan | Req Doc | Design Doc | Prototype | History | Revision |