A functional chat server and client.
Go to file
2017-04-02 18:44:01 -04:00
feasibility_analysis testdrive.md to README.md. We can have nested *.mds 2017-04-02 02:15:53 -04:00
architecture_diagram.png updated architecture diagram 2017-04-02 11:28:49 -04:00
FP4-instructions.md Added FP4 instructions from oplS17projects/FP4-proposal as FP4-instructions.md 2017-03-28 16:24:26 -04:00
Gui_Exploration.rkt Messing around with framework GUI 2017-03-30 22:02:27 -04:00
README.md formatting updates to README.md 2017-04-02 18:44:01 -04:00

Hermes

Statement

Hermes is a multi-client chat program akin to IRC written in Racket. Building Hermes is interesting as it exposes us to various design problems namely networking, synchronization, scheduling, and GUI design.

Analysis

Will you use data abstraction? How?

TCP communication will be abstracted away so will only deal with Hermes definition of a message. We will try to encrypt the messages passed around. The encryption will be abstracted away so we only have to think about it once during implementation

Will you use recursion? How?

The server will continually loop waiting for connections from clients. The Gui will continually loop to handle input with the user, and to and fro Hermes.

Will you use map/filter/reduce? How?

Map will be used for dealing editor area of clients.

Will you use object-orientation? How?

Keeping account of the number of clients will require an object of some sort. With procedures to increment and decrement the number of users

Will you use functional approaches to processing your data? How?

The communication part of Hermes is over tcp which uses a lot of functional approaches e.g. you start a listener which you can then pass to tcp accept. The result of tcp accept are two pairs of ports which we can then bind to some variables.

Will you use state-modification approaches? How? (If so, this should be encapsulated within objects. set! pretty much should only exist inside an object.)

State-modification will be used e.g. keeping count of logged in users requires state modification via set! to maintain the true user account

Will you build an expression evaluator, like we did in the symbolic differentatior and the metacircular evaluator?

Users will type their input into a text field from the GUI. We will retrieve the command and evaluate it to see if its a message, or a command to change GUI state. We will do something that resembles the metacircular evaluator.

Deliverable and Demonstration

There are two big deliverables for this project. Code for the server(Hermes, get it?), and the clients which not only has code for interacting with Hermes, but also a GUI for interactivity with a user like myself.

We plan to demonstrate Hermes by running the server code on a remote machine. We will connect to the server via our PCs running client code. We will ssh into the remote machine to see the server running. Since Hermes is a multichat anyone can join in the demonstration by connecting their computers to the remote machine!

Evaluation of Results

Evaluating Hermes is very simple. Can at least two clients hold a meaningful conversation remotely? If Client A speaks at 11:01 am, and client B does so at 11:01 plus a few seconds, Hermes has to convey this state correctly.

Architecture Diagram

Diagram

Schedule

The first step in out project will be to setup a system to get data from one machine to another. What data exactly isn't directly important and the other machine doesn't really need to display it in a pretty manner, it just needs to relay that it has recieved the correct information.

Next we need to create a user interface that looks nice. Some way to control the connection and display information in a convient and readable format.

After we have finished the user interface and connecting the machines, we will need to merge them together and begin expanding the utility if time permits.

First Milestone (Sun Apr 9)

Get two different machines to relay information.

Second Milestone (Sun Apr 16)

Get a GUI that looks professional and uses the correct format

Public Presentation (Mon Apr 24, Wed Apr 26, or Fri Apr 28 [your date to be determined later])

Merging the GUI and information relay together into one program. If time permits we also plan on adding additional features.

Group Responsibilities

Douglas Richardson @Doug-Richardson

Will write the GUI

Ibrahim Mkusa @iskm

Will write the code