updates to README.md
This commit is contained in:
parent
bd7b3bb531
commit
f072a77550
39
README.md
39
README.md
@ -13,19 +13,22 @@ definition of a message.
|
||||
|
||||
> Will you use recursion? How?
|
||||
|
||||
The server continually loops waiting for connections from clients.
|
||||
The server continually loops waiting for connections from clients. The clients
|
||||
are always on standby to receive input.
|
||||
The GUI continually loops to handle input from the user,
|
||||
as well as to keep the canvas it writes the messages on updated.
|
||||
|
||||
> Will you use map/filter/reduce? How?
|
||||
|
||||
Map will be used for dealing with input area of clients, and iterating over a list
|
||||
of open ports to send messages.
|
||||
Map was used for dealing with input area of clients, and iterating over a list
|
||||
of open ports to send messages. Filter was used to find the recipient of
|
||||
a whisper.
|
||||
|
||||
> Will you use object-orientation? How?
|
||||
|
||||
Keeping count of the number of clients required working with objects that are able to
|
||||
increment and decrement the number of users.
|
||||
increment and decrement the number of users. We handled a list of connection
|
||||
ports, messages similarly.
|
||||
We also keep the GUI in an object so the many moving parts of the
|
||||
user interface are packaged in one place.
|
||||
|
||||
@ -34,18 +37,20 @@ user interface are packaged in one place.
|
||||
The communication part of Hermes is over tcp which uses a lot of functional
|
||||
approaches e.g. you start a listener which you can call tcp-accept on.
|
||||
The result of tcp accept are two pairs of ports which we can then bind to some
|
||||
variables.
|
||||
variables. Functional approaches are exemplied in most of the code base.
|
||||
|
||||
> 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.
|
||||
State-modification was used e.g. keeping count of logged in users requires
|
||||
state modification via set! to maintain the true user account, managing the list
|
||||
of open connections and messages required state-modification.
|
||||
The user interface also needs a few states that it needs to keep up to date.
|
||||
|
||||
> Will you build an expression evaluator, like we did in the symbolic differentatior and the metacircular evaluator?
|
||||
|
||||
We allow the use of a few commands through the user interface. The most notable ones
|
||||
are the /quit command to shut down a connection and the /color command to allow
|
||||
We allowed the use of a few commands through the user interface. The most notable ones
|
||||
are the /whisper to send private messages to a user, /list count and /list users
|
||||
to view user statistics , and the /color command to allow
|
||||
the user to change the color of their text.
|
||||
|
||||
### Deliverable and Demonstration
|
||||
@ -53,7 +58,7 @@ There are two big deliverables for this project. Code for the server
|
||||
, and the clients which not only has code for interacting with Hermes,
|
||||
but also a GUI for interactivity with a user.
|
||||
|
||||
We will demonstrate Hermes by running the server code on a remote machine.
|
||||
We are going 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
|
||||
@ -62,11 +67,10 @@ machine!
|
||||
|
||||
|
||||
### Evaluation of Results
|
||||
Evaluating Hermes is very simple. Can at least two clients hold a meaningful
|
||||
Evaluating Hermes was 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. Is the GUI
|
||||
intuitive for current irc users? When we can successfully answer this questions
|
||||
satisfactorily we would have met our goals.
|
||||
intuitive for current irc users? We successfully met these questions, and more.
|
||||
|
||||
|
||||
## Architecture Diagram
|
||||
@ -104,8 +108,7 @@ that the server provides. For the most part the program only interacts with the
|
||||
through the GUI.
|
||||
|
||||
### Ibrahim Mkusa @iskm
|
||||
Will write the networking code i.e. code that allows communication between
|
||||
clients through server. I will also write scheduling code responsible for queueing
|
||||
fairly and orderly the client messages and broadcasting to the rest of connected
|
||||
clients. If time permits, i will also be responsible for authenticating users
|
||||
via a backend database.
|
||||
I have written the networking code i.e. code that allows communication between
|
||||
clients through server. I wrote scheduling code responsible for queueing
|
||||
fairly the client messages and broadcasting to the rest of connected
|
||||
clients. Implemented the logic for handling /list, /whisper commands.
|
||||
|
Loading…
Reference in New Issue
Block a user