This project entails designing a website using GWT, Java, PostgreSQL, and Hibernate that facilitates two-way chat between users. The requirements are: 1) There must be a login and registration mechanism. Users that choose to not log in are assigned a temporary ID starting with the word "guest", followed by a dash, ending in a string of unique digits. 2) There must be a mechanism to store a "buddy list" of favorite people to contact for users that are loggged in. The buddy list is a separate GWT panel that can be popped out as well. This list does NOT need to track the status of users as to whether they are online or offline. The buddy list needs to have functionality to add and remove users from it (specifying the external user's name and alias). 3) The chat sessions must be in separate windows. They can be GWT panels on the same webpage. The user should be able to drag and resize them and the borders and styles should be easily modified. 4) The chat sessions must support GMail style pop-out windows so they can keep the windows open while they have their browser minimized. 5) The site must log the IP addresses of each user (logged in or guest) with their ID and a timestamp. 6) The site must block users from logging in more than once. 7) There must be a mechanism to efficiently poll the database for new messages. This means that a GWT RPC call must be made that requests the next message. If no messages are waiting then it delays on the server side until there is a message. If the client times out it should perform the GWT RPC call again. This is the Wait, Respond, Close, Re-Open paradigm explained in the GWT Server Push FAQ. The database must contain the following items: 1) A table of users with login IDs, usernames, passwords (hashed), and e-mail addresses 2) A table of messages. When a user sends a message it should be added to this table with information containing the sender and the external recipient along with a timestamp. 3) A table of external recipients. External recipients are users that are on other chat systems (all chatting is done from a local user to an external user). There will need to be a field for the external user's name and an alias. 4) Any other tables required to implement the requirements from above. All foreign key references must be done by unique ID so that no information is duplicated.
This project does NOT cover the external communication portion of the project. An external process handles putting and getting messages into and out of the database.