ChatApp Project

For the latest ChatApp information, please see the ChatApp Resources page in Canvas!

The ChatApp program is a general message sending and receiving application that is not limited to simple text message but should be able to send and receive arbirtrary custom messages defined solely by the sender, not the receiver.

In addition to the technical design and implementation challenges of the application, a key component of the project is to design the common application programming interface ("API") that defines the remote connectivity between ChatApp apps and the transmitted data sent between them. The process of creating this API will be a class-wide effort through competing API design groups. This effort has two critical components:

• The modeling of the abstract representation of the remote connected ChatApp applications and the data being transmitted between them.
  • The API should conform to some basic modeling principles. See ChatApp APIs and Interfaces
• Convincing the rest of the class as to the merits of one's proposed API.
  • There are many viable ways to design the ChatApp API, so effective and persuasive presentation of the proposal is crucial. It is insufficient to merely have good ideas and technical prowess, one must be able to convince others of the merits of one's work.
  • See API Design and Evaluation Considerations

Resources:

• See Canvas for a "ChatApp Resources" page
• ChatApp API Interfaces
• Generic Extended Visitors and Datapackets
• Mini-MVCs for multiple chatrooms
• Message routing is unnecessary!
• Datapacket processing
  • Basic datapacket processing
  • Unknown datapacket processing
  • Connecting remotely-sourced commands to the local system.
  • Avoiding deadlocks
• Design Process
  • Design Process Overall Guidelines
  • API Design and Evaluation Considerations
• ChatApp and Final Project Communications Pathways
• ChatApp: A Guide To Survival (written by ex-COMP310 TA's Rishu Harpavat and Holden Lippert)

ChatApp Design Considerations

Some things (non-exhaustive!) to think about:

• To one person, in terms of RMI, what is another person (user) that the first person can send a message (data packet) to?
• What is a chat room anyway?   
• What does it mean to send a message to everyone in a chat room?
• Connection Use Case:   What happens when we first attempt to connect to another computer?
  • What must be true about the target computer before it is connected to?
  • What must be known about the Registry on the target computer?
  • What if the target computer has not connected to anyone else yet?
  • How does this change the initial connection use case? 
• What sorts of data packet types does everyone need to know about?   (One possible answer is much smaller than you think!)

Some (non-exhaustive!) important capabilities the ChatApp program needs

1. Use case for adding a user
   • Adding to local chat room vs. adding to remote chat room
   • What is the process for adding yourself (i.e. one of your own message reeivers) to a room?
     • Be careful about creating infinite loops!
2. Processing DataPacket<T>
   • "Well-known" data types?   The need to be able to unequivocally identify the purpose of a datapacket.
3. Return value of sending a data packet?   
4. Comparing remote stubs and serialized objects.
   • See the Resources web page on the subject.
   • What if two people have the same name?   Does the message receiver stub provide enough information through its remote methods to uniquely identify the remote message receiver?
5. Processing new commands
   • Attaching the local view, and other model access, e.g. getting the local message receiver to incoming data packet processing commands
   • What if the new command wants fancier view access, e.g. a new display window or custom GUI?
     • Pop-up dialogs are no problem because they don't attach to the local GUI and thus can be made independently of the local view.

Project Developement Issues

All Design Teams need to record the HW08 teams (NOT single individuals!) assigned to each role.   Please record both the HW08 team number (1-34) and the people in that team.   DO THIS NOW!!

See the Design Process Overall Guidelines.

All design groups need to get moving on the design process right away.   DO NOT DELAY!    THERE IS A HUGE AMOUNT OF WORK TO DO! 

 Develop and test your API incrementally.   As soon as you decide on a part of your API, e.g. the initial connection process, commit that much of your API to your groups common repository and let the HW08 teams implement it and test it with each other.    Then as the design group decides on another part of the API, commit that and let people add that implementation and test it.   DO NOT WAIT UNTIL EVERYTHING IS COMPLETE TO START IMPLEMENTING AND TESTING!

Remember, most of ChatApp can be written without knowing the API! 

TEST YOUR PROPOSED API! Write code to try to get your proposed API to work.

1. Create an implementation of your group's interfaces in your own rmiChat package and build your code off of that.  
2. Add/modify methods, interfaces as you think are necessary to make the chat system work.  
3. Document your changes and suggestions in the wiki.
4. Post change and modification ideas to Piazza, requesting everyone to please look at your suggestions.

© 2020 by Stephen Wong