[Protokół] - Zmiana mechanizmu komunikacji klient <-> serwer.

[jam231]

Bardzo lakoniczny tytuł, ale chodzi mi o stworzenie dwoch nowych typów wiadomości: OK, FAIL które byłyby wysyłane po każdym po każdym requescie użytkownika. To, że teraz ich nie ma było chyba(?) powodane tendencją optymalizowania co się da, a to ból ich nie mieć - ból dla klienta. Teraz jest niekonsekwencja - w pewnych wypadkach serwer wysyła, że coś jest nie tak (registerfail, loginfail, unrecognizeduser), a w innych nie.

No dobra, a teraz pytanie o informacje zawarte w tych wiadomościach:

1) OK - tutaj nic nie trzeba podawać, TCP gwarantuje dostarczenie danych "in-order", wiec klient będzie wiedział, czego się tyczy. 2) FAIL - obecnie (vide register\login) jest przysyłany string z wiadomością co jest nie tak... i to chyba ja wpadłem na ten jakże syfiasty pomysł... proponuje zamiast stringa status jako np. qint8 (ew. po statusie może być string jak się znajdą przekonujące argumenty).

[kaiks]

[OK] ;)

@string: Jak dla mnie taka mozliwosc powinna byc, np jesli mielibysmy pare wersji klientow to czasem lepiej miec jednak opis niz 'unknown error' ;D

sa tez co do tego dwie watpliwosci: 1) skonczy sie na tym, ze 1/3 komunikatow taki opis bedzie miala (w zaleznosci od nastroju programisty) 2) myslenie o paru wersjach klientow jest dosc slabo uzasadnione na obecnym etapie prac ;D

PS: wzialbys sie za PGK, a nie...

[jam231]

No dobra, ale przecież równie dobrze można dodać nowy status błędu. Nie wyobrażam sobie, żeby po stronie serwera zaistniał przypadek kiedy mając wiedze o błędzie serwer nie miałby wysyłać odpowiedniego statusu. "unknown error" byłby wysyłany (jeżeli w ogóle) tylko w sytuacjach kiedy opis i tak miałby równoważna treść.

No i po za tym matchowanie statusów (vide wygoda po stronie klienta) jest o niebo lepsze, niż stringów.

[kaiks]

chodzi mi o to, że jeśli jest klient z dnia X, a serwer zmienia się (w niewielkim stopniu) w dniu X+3, to fajnie byłoby, żeby klient (tj. człowiek) w dniu X+5 nadal wiedział, dlaczego taki błąd wystąpił

Oczywiście z samą ideą przewagi statusów nad stringami się zgadzam. Dodatkowo fajnie by było, jakby były one przechowywane (np. tutaj na repozytorium) w jakimś formacie innym niż enum w headerze, np. w jakimś jsonie, albo chociaż w zwykłym pliku tekstowym

[jam231]

Tak, zamierzam zrobić jakiś dokument opisujący protokół i przy ewentualnych zmianach wrzucać lekko zmieniona kopie nie usuwając starych wersji. No i na wiki powinna być opisana aktualna wersja.

Co do pierwszej części: Nie bardzo rozumiem argument. Chodzi Ci o problemy przy debugowaniu ? Strasznie naciągane wydaje się to, że ktoś ma buga w kliencie, tj. dostaje kod błędu z jakimś statusem, po czym nie zadaje sobie trudu zajrzenia co ten status znaczy. No dobra, takie rzeczy się zdarzają, no ale to przeciez można zajrzeć do historii odpowiedniego pliku na gitcie, albo do dokumentów jeżeli będą. Dublowaine informacji, żeby być lazyass-friendly wydaję niewłaściwe.

[kaiks]

Dublowaine informacji, żeby być lazyass-friendly wydaję niewłaściwe.

Jak uważasz. Mówiłem to w hipotetycznej sytuacji jeśli klient miałby pójść gdzieś w świat (którą, AFAIR, parę razy już sugerowałeś), wtedy użytkownik końcowy nie otrzymywałby w przypadku drobnych zmian komunikacji unknown error, skonsultuj się z lekarzem lub farmaceutom, a coś konkretnego.

Nie wiem też, czy myślimy o tym samym, gdy piszesz o dokumencie opisującym protokół - mi chodziło o coś, co pozwoli zrobić ctrl+c, ctrl+v do mojego klienta po aktualizacji, a nie o coś, co będę mógł przeczytać.

[jam231]

Powinno być tak, że protokół z dnia X+5 nie powinien zawierać nowych wiadomości wyjściowych w porównaniu z protokołem z dnia X. Jeśli dopuścimy taką sytuacje, to myślę, że problem z nowym statusem błędu nie bedzie dużym problemem - można raczej łatwo przewidzieć wszystkie błędy, które użytkownik może otrzymać dla danych requestów. Dużym problemem natomiast byłoby to, że użytkownik nagle mógłby dostawać nowe wiadomości i tutaj nie ma rady. Stringi dla wiadomości typu failure rozwiązują tylko dla tego jednego typu wiadomości problem rozszerzenie protokołu, a dla pozostałych on pozostaje - nie sądze więc że warto, bo nic specjalnie sie na tym nie ugra.

Hmm, no rzeczywiście się nie zrozumieliśmy :D Raczej tak, przy okazji pisania jakiegoś agenta do testów integracyjnych\funkcjonalnych.