On Saturday, June 6, 2020 at 9:00:07 PM UTC+2, Maciej Sobczak wrote:
> > Po pierwsze, to aż się prosi, żeby ten serwer był zwykłą klasą. Czemu ktoś nie
miałby sobie stworzyć 5 serwisów WWW działających na różnych portach?
>
> No właśnie. I tu poruszamy ważną kwestię. Bo piszesz, że aż się prosi, ale potem
okazuje się, że nikt nie prosi, tylko czemu ktoś by miał nie prosić.

Czyli ograniczasz użytkowników do jednego przypadku i to w sytuacji, gdy dodanie
jednego stopnia swobody nie kosztuje ani użytkownika, ani Ciebie nic.

> A mi chodziło o to, żeby pakiet 1.0 przekroczył próg używalności a nie o to, żeby
rozwiązać problemy typu "czemy ktoś nie miałby".

Żeby Twojego rozwiązania użyć w jakimś normalnym programie, trzeba stworzyć wątek.
Wygodne użycie, to byłoby coś takiego:

int main() {
auto server = std::make_unique<http::Server>(8008, ".");

// tu sobie programista coś inicjalizuje

server->start();

// tu się dzieje magia, która programista uprawia
// a gdy się kończy scope, to server się sam zamyka
}

> Natomiast, nic nie stoi na przeszkodzie, żeby sobie zawołać funkcję server_start()
5 razy z różnymi portami, z 5 różnych wątków, bo ta funkcja i tak nie ma stanu
globalnego. Nie trzeba mieć do tego klasy.

Stoi, bo masz współdzieloną mapę routingu. A, że masz ją współdzieloną, to też masz
radosnego mutexa w głównej pętli.

> > Po drugie, nie ma sposobu na zamknięcie serwera, poza zabiciem procesu. Chyba, że
ja czegoś nie widzę.
>
> Tak. Funkcja server_stop() już istniała, ale ją usunąłem. To nie jest oczywiste,
jak zamknąć serwer, który ma callbacki, niektóre zapewne w trakcie pracy.
> Wszystkie problemy da się rozwiązać, ale nie o to chodziło w wersji 1.0.

No i to jest defekt. Ja chcę, żeby mój program się zamykał w cywilizowany sposób.
Callbacki są wołane w wątkach, robisz sobie na nie barierę (czyli np. latch) po
zakończeniu głównej pętli i po kłopocie.

> > Mówiąc o API: 6 wariantów register_{generic,html,text}_{post,get}_action można by
sprowadzić do 2. register_action(const char* name, {post_action_type,
get_action_type} callback, const char* mime_type).
>
> Nie, bo po pierwsze generic i html różnią się obsługą a po drugie nie chciałem
przeciążać funkcji register, bo bardziej naturalne wydaje mi się przeciążenie funkcji
akcji dla get i post:
>
> void my_action(to-co-trzeba-dla-get) { ... }
> void my_action(to-co-trzeba-dla-post) { ... }
>
> I wtedy nie dałoby rady:
>
> register(my_action);

To jest koślawe, sorry. W HTTP masz nie tylko akcje GET i POST, ale i chyba ze 20
innych. Poza tym założenie, że ktoś będzie argumenty POST przesyłał w URL-u jest
zdziebko przestarzałe, o wiele wygodniej jest słać parametry w JSONie.

> > Zresztą, może lepiej byłoby przyjmować jako argument mapę akcji - czyli to co
masz teraz w get_actions/post_actions. Niech user sobie przygotuje takie mapy w
sposób, jaki mu pasuje, a ty pozbędziesz się potrzeby blokowania tych struktur.
>
> Ale teraz obsługa jest prostsza, właśnie dlatego, że user nie musi robić takich
map.

Pamiętanie o kilku wariantach funkcji nie jest prostsze. Już lepiej byłoby mieć jedną
przeciążoną metodę register i kilka pomocniczych funkcji w stylu "make_get_action".

> Można by było pomyśleć o akcji catch-all. Tam user dostawałby wszystko (co nie było
obsłużone) i mógłby sobie tam zrobić takie mapy, jakie zechce.
>
> > Czasem funkcje przyjmują const char*, czase std::string& co jest niespójne.
>
> Bo chodziło o przewidywane użycie. Tam gdzie przewidywałem literał, jest const
char*.

const char* to nie tylko literały, tego założenia nie da się odczytać z API.

> > W ogóle nie walidujesz, czy wskaźniki są niepuste. Tak samo z std::function.
>
> A po co? Bez przesady z tą walidacją. Walidować należy input z zewnątrz (i nawet
opisałem to w przykładzie 3, z parametrami) a nie własne literały.

Bo programista się czasem myli, więc powinien się koncentrować na błędach w kodzie,
który pisze, a nie którego używa.

> > Zero testów. Serio? :)
>
> Są testy. W katalogu, który dla zmylenia przeciwnika nazywa się examples. :-)
>
> A jakieś inne testy byś chciał?

Np. testy jednostkowe parserów, których jest co najmniej ze 2. Jak widzę
5-krotnie zagnieżdżony kod, to nie wiem, czego się spodziewać.

w.