Feedback Manual

.gitignore

@@ -0,0 +1,4 @@
+/target/
+/.idea/
+/server/target/*
+/client/target/*

README.md

@@ -1,27 +1,57 @@
-# Frobnicator
+# Chatter
 
-## Autorzy
-- Andrzej Głuszak (gr 9, @agluszak na githubie)
-- Linus Torvalds (Uniwersytet Helsiński, @torvalds na githubie)
+## Autorzy:
+	Kacper Kramarz-Fernandez,
+	mgr inż. (XD) Jan Zembowicz
 
-## Opis
-Od zawsze chcieliśmy napisać grę komputerową.
-Frobnicator będzie to gra platformowa, w której chodzi o to, żeby...
+## Opis:
 
-Z grubsza będziemy wzorować się na [tym tutorialu](https://dev.to/sbelzile/rust-platformer-part-1-bevy-and-ecs-2pci).
+	Projekt stanowi system prostego czatu o pojedynczym pokoju i dowolnej liczby klientów.
+	Dzieli się on na:
+	- Klient - umożliwia nadawanie wiadomości oraz odbieranie ich i wyświetlanie 
+	- Serwer - stanowi pokój, odbiera wiadomość wysłaną przez klienta i rozsyła ją do wszystkich pozostałych
 
-## Funkcjonalność
-- Generowanie map
-- Strzelanie
-- AI dla wrogów (bardziej rozbudowane niż w tutorialu)
-- Możliwość zapisywania i wczytywania stanu gry
-- Punktacja
+## Funkcje: (<i>"ponieważ funkcjonalność to stan, w którym coś funkcjonuje"</i> - Jan "prof. Miodek" Zembowicz)
+
+	- Klient: dwuprocesowy program:
+		1. Wysyłanie wiadomości za pomocą requesta typu GET, wiadomość wysyłana w parametrze URL wraz z nią timestamp
+		2. Odbieranie wiadomości asynchronicznie za pomocą klienta WebSocket i wyświetlenie ich w terminalu
+	- Serwer: prawdopodobnie dwuwątkowy
+		1. Odbiera requesty HTTP od pojedynczego klienta
+		2. Wysyła odebraną wiadomość po WebSocket do wszystkich obecnie połączonych klientów
 
-## Propozycja podziału na części
-W pierwszej części stworzymy grę opartą na tutorialu (z lepszym AI) i jedną zahardcodowaną planszą.
+## Podział pracy
+	Uwaga: zaproponowany podział jest płynny!
+
+	Początkowo
+	- Jan: podstawowa komunikacja sieciowa
+	- Kacper: przeniesienie zaimplementowanych mechanizmów przez Jan na kod o wyższej jakości, zgodny z dobrymi praktykami tworzenia oprogramowania w języku Rust
+
+	Etap 2:
+	- Jan: system heartbeat + indeksowanie klientów WS po username
+	- Kacper: Wiele pokoi + msg storage 
 
-W drugiej części dodamy do tego losowy generator map, zapisywanie/wczytywanie stanu gry oraz system punktacji.
 
-## Biblioteki
-- Bevy
-- może coś do serializacji danych? (czy mógłby Pan coś polecić?)
+## Podział projektu na części
+    Sprint 1
+        - wysyłanie i odbieranie podstawowych komunikatów z timestampem,
+    Sprint 2
+        - wiele pokoi, historia wiadomosci, heartbeat, polaczenie "displayera" za pomocaą username
+
+## Biblioteki i zależności:
+
+	- Wysyłanie requestów HTTP: reqwest
+	- Serwer HTTP: ??? (prawdopodonie punktem wyjścia będzie jeden z przykładów biblioteki `hyper`)
+	- Serwer i klient WebSocket: ???
+
+
+## Struktura repo
+	- server - folder z projektem servera
+	- client - folder z projektem clienta
+	- common - wspolny kod dla obu projektow
+
+## Uruchomienie
+
+	$ cargo run
+
+	W katalogu odpowiednio dla serwera oraz klienta

TODO.md

@@ -0,0 +1,22 @@
+Notatki, ale jeszcze je troche przemyślałem, zagadnienia w kolejności dodawania:
+
+
+1. Mapa userow indeksowana userName (janek)
+- [ ] Wkladamy userow do mapy userow dopiero po otrzymaniu z WS ich nicka (nick zawarty w JSON)
+2. Heartbeat (janek)
+- [ ] struktura reprezentująca usera (WSClient) otrzymuje pole bool: isAlive
+- [ ] dodajemy endpoint /heartbeat, w parametrze username, po zawolaniu ustawia zadanemu userowi isAlive na true
+- [ ] dodatkowy wątek sprawdzający isAlive == true, jeśli nie to zamykamy połączenie WS, wysyłamy "user has left the char czy cos"
+- [ ] jeśli zawołanie /heartbit sie nie powiedzie (timeout) - client informuje o zawieszeniu połączenia
+3. Pokoje (kacper)
+- [ ] robimy mapę key: nazwa pokoju, value: struct reprezentujący pokój
+- [ ] zawartość structa reprezentującego pokój: tablica z nickami
+- [ ] do endpointa /send (lub /post, nie pamietam, ten od wysyłania) dodajemy nazwe docelowego pokoju w postaci nowego pola common::Msg
+- [ ] wywołanie handlera send sprawdza do którego pokoju ma wysłać wiadomosci i wysyla do wszystkich userów
+- [ ] Rejestracja pokoju odbywa sie poprzez endpoint /createroom (w parametrze nazwa nowego pokoju), metoda http wołana gdy w prompt wybieramy nowy pokoj LUB (ale to zostawiam twojej dyspozycji realizacje tej rejestracji, jest wiele sposobow)
+- podczas podłączania WS do jsona z pkt 1. (ten z nickiem) dodajemy również pożądany pokój
+4. Msgs archiwum
+- [ ] do kazdego pokoju dodajemy tablice z archiwalnymi msgami
+- [ ] w momencie podłączenia, wysyłamy po ws wszystkie dotychczasowe wiadomości
+
+ELO