> Niby tak, ale już cooperative tak nie obskoczysz.

I naiwna abstrakcja wątków też by mi tego nie dała.

> Ponadto praktyka pozkauje że zmiana "jednej linijki" w biblitece nie
> jest prawidłową metodą dopasowania się do czegoś bo za chwile tej
> linijki nie będzie w wersji 0.9.3.

I tu płynnie przechodzimy do pytania o to, gdzie jest właściwy poziom abstrakcji. Bo
Ty chciałbyś, żeby w bibliotece HTTP była abstrakcja wątków na wypadek portowania na
inną platformę. A ja pytam, dlaczego cały serwer HTTP nie miałby być tą abstrakcją, z
różnymi implementacjami na różne platformy?

Cała ta biblioteka ma dokładnie 2 pliki .cpp. Słownie: dwa. Plus 2 headery do nich. I
działa na Lin/Mac/Win. Dołożenie do niej abstrakcji na okoliczność egzotycznych
platform wbudowanych z pół-wątkami i dziwacznymi stosami TCP spowodowałoby, że tych
plików byłoby 10. Albo 30.
I nawet nie wiem, jaka jest realna nisza rynkowa z takimi potrzebami i czy ona w
ogóle jest. Bo nisza na wersję 1.0 jest na pewno, bo w szczególności ja sam tego
użyję. Natomiast te abstrakcje rozwiązałyby problem ludzi o których nawet nie wiem,
czy istnieją.

A nie lepiej poczekać, aż ktoś *realnie* zgłosi taką potrzebę i wtedy zrobić port
tych dwóch plików z zachowaniem API całego serwera HTTP? I wtedy taki port też będzie
miał 2 pliki .cpp. I ani kawałka kodu więcej.

Tak, będzie parę linijek zduplikowanych. Ale przekonaj mnie teraz, że koszt tych
wszystkich abstrakcji jest mniejszy.

> To tylko łatwo w teorii, w normalnych systemach "podmienianie"
> std::whatever to jest *gruby* hacking...

Ale przecież nie pisałeś o normalnych systemach. :-)
Na normalnych to wszystko działa out-of-the-box i nie trzeba nic hacking.

> Niby tak, ale znowu: co dziwnego w tym że robisz własną abstrakcję do
> "ich" abstrakcji?

A co dziwnego w tym, że ich nie robię i zamiast tego proponuję minimalne rozwiązanie
dla 99.9% potencjalnych odbiorców?

> Piszesz rdzeń HTTP w oderwaniu kompletnym od tego jaki stos TCP używasz.

Przecież tak jest teraz. Dlatego są tam dwa pliki .cpp. Jeden to rdzeń HTTP a drugi
to IOStreams na "typowym" stosie TCP.

> *wszystkie* interfejsy GUI jakie istnieją w sensownym zastosowaniu są
> event-based czyli takie coroutines/cooperative.

To ciekawa uwaga. W tej bibliotece nie ma na wierzchu niczego podobnego do kolejki, a
co za tym idzie nie zmusza się użytkownika do kręcenia własną pętlą zdarzeń. Pod tym
względem ta biblioteka bardziej przypomina lekki framework komunikacyjny, niż typowy
framework GUI. Ale to dobry zbieg okoliczności, bo akurat HTTP jest protokołem
komunikacyjnym. A kolorowe jarmarki na display'u i tak zrobisz w JS.

Czyli zamiast odpowiadać na pytanie jak zrobić GUI, odpowiadamy na pytanie, jak
zrobić komunikację z tym czymś co robi GUI[*].

[*] I bez ograniczania się tylko do tego zastosowania (chociaż GUI było motywacją).
HTTP może służyć również do innych rzeczy, niż GUI. I dlatego też to się nazywa
"Embedded HTTP Server" a nie "GUI Framework".

--
Maciej Sobczak * http://www.inspirel.com