W szkielecie klienta okienkowego zawiera się:

• Działający system budowania (np. Gradle, Maven)
• Przykładowy program w Javie wykonujący pewną akcję
• Ewentualnie zautomatyzowane testowanie
• Ewentualne moduły wymagane przez projekt

W szkielecie klienta mobilnego zawiera się:

• Działający system budowania
• Przykładowy program w Kotlinie wykonujący pewną akcję
• Ewentualnie zautomatyzowane testowanie
• Ewentualne moduły wymagane przez projekt

Nazwy do poprawy:

• Epoll -> EpollDevice
• Streambuf -> FdBuf

Serwer powinien odpowiadać na najprostsze zapytania użytkownika, takie jak:

• pwd
• ls
• cd

Projekt potrzebuje dokumentacji końcowej zgodnej z wytycznymi.

Potrzebne są:

• Plik z listą użytkowników w katalogu .tds,
• Implementacja instrukcji tds user [<add|passwd|remove|perms>] ...,
• W nowo utworzonej instancji powinien znaleźć się domyślny użytkownik o loginie admin, haśle admin i wszystkich uprawnieniach.

Proponowany schemat listy użytkowników:

username1:passwd1:perms1
username2:passwd2:perms2
...

Hasło powinno być "zahaszowane" z wykorzystaniem odpowiedniego algorytmu, np. Keccak.

W szkielecie klienta konsolowego zawiera się:

• Działający system budowania (CMake)
• Przykładowy program w języku C wykonujący pewną akcję
• Ewentualnie zautomatyzowane testowanie
• Ewentualne moduły wymagane przez projekt

Plik .editorconfig powinien uwzględniać wszystkie języki, które będą pojawiać się w projekcie. Są to:

• C++
• C
• Kotlin
• Java
• LaTeX
• CMake
• Bash
• YAML

Serwer powinien włączać z powrotem echo w terminalu.
Błąd występuje też w przypadku instrukcji tds user.

Wykryto w Arch Linuksie.

Problem z serwerem uruchomionym w WSL - użytkownik po rozłączeniu się wpada w nieskończoną pętlę.

Plik konfiguracyjny dla narzędzia clang-format powinien zniknąć z katalogu głównego - nie jest on istotny dla całego projektu.

Opis komunikatów powinien znaleźć się w dokumentacji.

Projekt serwera powinien mieć swoje CI.

Serwer powinien wypisywać swoje logi nie tylko na ekran, ale także do dodatkowego pliku (.tds/log).

Tzw. katalog konfiguracyjny .tds powinien być jednym, lekkim i czytelnym plikiem w formacie TOML.

Potrzebna jest implementacja tworzenia instancji serwera (polecenie tds init).

Serwer powinien obsługiwać najniższą warstwę komunikacyjną - gniazda.

Test klasy SignalDevice blokuje się w WSL.

TDS powinien umożliwiać edycję konfiguracji z wykorzystaniem linii komend, np.

tds config max_user_count 256 # Zmiana maksymalnej dozwolonej liczby użytkowników

Potrzebne są proste narzędzia do obsługi warstwy sieciowej, czyli między innymi:

• Obsługa adresu IPv4
• Obsługa resolvera
• Reprezentacja "punktu końcowego" (adres IP + port)

Klient okienkowy powinien obsługiwać najniższą warstwę komunikacyjną - gniazda.

Plik .gitignore w katalogu głównym jest do niczego (są w nim istotne błędy), więc:

• Trzeba go poprawić lub
• Trzeba go usunąć (wtedy będą potrzebne pliki .gitignore w podprojektach).

Projekt potrzebuje podstawowej konfiguracji:

• Konfiguracji edytora (.editorconfig) dla wybranych języków
• Konfiguracji formatowania (dla C i C++)
• Licencji
• README
• Pliku .gitignore (dla C i C++)
• Listy właścicieli kodu

Projekt klienta konsolowego powinien mieć swoje CI.

TDS powinien umożliwiać wyświetlanie logów serwera na konsoli. Przykład użycia

tds log # Wyświetli logi z ostatniego uruchomienia serwera

Plik CODEOWNERS powinien odzwierciedlać podział pracy w zespole - każdy członek zespołu powinien mieć katalog ze swoim projektem.

Serwer nie powinien się wyłączać przy rozłączeniu jednego klienta.

Wykorzystanie programu CPack możliwi to łatwiejszą instalację programu np. na systemach opartych o Debiana.

Potrzebne jest narzędzie (dziedziczące po IoDevice) do czytania sygnałów systemowych takich jak SIGINT (Ctrl+C).

Potrzebne są proste narzędzia do obsługi warstwy transportowej (protokołu TCP), czyli między innymi:

• Klasa do nasłuchiwania (TcpListener)
• Klasa do obsługi połączeń (TcpConnection)

Plik .gitattributes może być lepszy, np. może zawierać dodatkowe reguły dla Linguista.

W szkielecie serwera zawiera się:

• Działający system budowania
• Przykładowy program w języku C++ wykonujący pewną akcję
• Ewentualnie zautomatyzowane testowanie
• Ewentualne moduły wymagane przez projekt

WONTFIX: linux::FdBuf zostało usunięte z projektu

Projekt potrzebuje dokumentacji wstępnej w formie pliku .pdf.

Projekt klienta mobilnego powinien mieć swoje CI.

Co można ulepszyć:

• IoDevice powinien mieć możliwość zamykania deskryptora nie tylko w destruktorze (funkcja close)
• IoDevice powinien mieć możliwość transferu deskryptora (funkcja release jak w std::unique_ptr<T>)
• Konstruktor IoDevice(int) powinien mieć dostęp chroniony (o ile będzie jeszcze potrzebny)
• Klasa EpollDevice nie powinna przechowywać bezpośrednio urządzeń, które obsługuje

W pliku README.md, oprócz składu zespołu, powinny znaleźć się następujące informacje:

• Znaczniki CI
• Poprawiony główny nagłówek (tytuł)
• Podział pracy w zespole
• Cel projektu
• Informacja o katalogach
• Informacja o wymaganych narzędziach

Klient konsolowy powinien obsługiwać najniższą warstwę komunikacyjną - gniazda.

Obsługa we/wy oparta o:

• Specjaną klasę dziedziczącą po std::streambuf, która pisze i czyta z deskryptorów
• Klasę do obsługi mechanizmu epoll
• Ogólną abstrakcję urządzenia we/wy (klasa po której będą dziedziczyć m.in. gniazda TCP, serwis obsługujący sygnały sygnały systemowe)

Do zrobienia:

• Obsługa wątków,
• Obsługa głównego epolla,
• Prawidłowe otwieranie połączeń i ich obsługa na wielu wątkach,
• Wstępne narzędzia do obsługi protokołu (tds::protocol), czyli między innymi lista kodów błędów, funkcje do wykonywania poleceń,
• Dodatkowe atrybuty dla EpollDevice jak np. one_shot (EPOLLONESHOT)

Serwer powinien reagować na proste sygnały zewnętrzne podczas wykonywania polecenia run.

Dodanie tej biblioteki uprości tworzenie wyjścia (stdout) oraz logów serwera.

Klient mobilny powinien obsługiwać najniższą warstwę komunikacyjną - gniazda.

System budowania powinien umożliwiać instalację serwera na lokalnej maszynie:

sudo cmake --build build --target install

Będzie to przydatne przy m.in. testach integracyjnych.

Projekt klienta okienkowego powinien mieć swoje CI.