> Ależ oczywiscie, przecież normalne jest że bibliteka zaczyna się od
> czegoś w rodzaju:
>
> IHttpServer* Factory::createServer(
> getTcpStreamsAbstractFactory()
> , getAbstractThreadsPoolFactory()
> , ConcurencyModel::Threaded
> );

Eee... Nie, to nie jest normalne. To jest overengineering.
Takich rzeczy mógłbym się być może spodziewać w kombajnach typu Boost, gdzie
jednocześnie mam od razu gotowe do wyboru fafnaście implementacji tych
polityk/aspektów, oraz oczywiście sensowne defaulty, żebym mógł po prostu napisać
createServer(). Ale w luźnych bibliotekach to jest overengineering.

> To ja decyduje jakie abstrakcjie to TCP i wątków dostarcze.

I nadal kogoś nie zadowolisz, bo parametryzowany mógłby być jeszcze sam protokół albo
w ogóle fakt istnienia jakiegokolwiek protokołu, szyfrowanie transmisji i jaką
metodą, alokator pamięci, metoda zamazywania zwolnionej już pamięci (bo jeszcze ktoś
podejrzy), i w ogóle kto powiedział, że to jest komunikacja TCP a nie serial po USB
albo przez Bluetooth i jeszcze pierdylion innych rzeczy, o których w poniedziałek
rano nie chce mi się myśleć.
I to wszystko to jest overengineering.

> Co złego w plikach ;) Myślałem że czasy MSDOSa słusznie minęły :)

Ale wtedy nie dałoby się napisać, że biblioteka ma 2 pliki. :-)

> > I nawet nie wiem, jaka jest realna nisza rynkowa z takimi potrzebami i czy ona w
ogóle jest.
>
> Nie ma. Sporo piszesz jeszcze jedną biblioteczkę do http to chyba nie po
> to aby zarabiać. Obecnośc niszy nie ma znaczenia.

Bingo. Ale skoro cel był inny, to ja ten cel chcę osiągnąć minimalnym kosztem.

> Jeśli nie zaimplementujesz jakiegoś ficzera to ludzie potrzebujący go,
> nie wezmą tej bibliteki.

Moje obserwacje: ludzie unikają potworów, których nie potrzebują. Zamiast tego
sięgają po proste rozwiązania, które z przyzwyczajenia wloką ze sobą przez swoją
karierę, zmuszając je do wzrastania razem z nimi i stawania się potworami w sposób
organiczny.
Czyli nie feature-bang, tylko raczej feature-creep.

> Taki przykład: embedowanie engine tcl-a do własnego kodu

Tak, jesteś wyjątkiem od reguły. :-)

> Jeśli prawidłowych abstrakcji nie zrobi się odpowiednio wcześnie

Odpowiednią abstrakcją jest rozwiązanie, któro jest proste.

> Koszt abstrakcji jest kosztem początkowym.

Ale nie wiesz jeszcze, które będą potrzebne. Więc wbrew pozorom to też jest
zaciągnięciem długu. Coś jak kupowanie wszystkich możliwych gadżetów wakacyjnych gdy
nie wiesz jeszcze, gdzie pojedziesz (i czy w ogóle).

> Wtedy można się zastanowić dlaczego miałbym brać takie *coś* zamiast
> QtHttpServer?

Bo skoro masz Qt, to nie będziesz robił GUI przez HTTP?
Idea jest taka, żebyś nie musiał mieć Qt.

> Prosiłeś o uwagi, nie miej pretensji że ktoś je zgłasza

W żadnym razie nie mam. Ani jednej. W ogóle cieszę się, że ktoś jeszcze żyje na tej
grupie. To dobra dyskusja, bo porusza ciekawe zagadnienia z teologii projektowania
produktów. Nie tylko programistycznych. Czy lepiej jest zrobić nożyk czy scyzoryk
szwajcarski? Przecież nożyk nie ma prawidłowych abstrakcji pozwalających z niego
zrobić zestaw dentystyczny. A jednak nożyki idą jak woda - właśnie dlatego, że nie
atakują użytkownika abstrakcjami, których nie potrzebuje.

> Innymi słowy Twoja bibliteka wymusiła pojawienie się w kodzie GUI
> synchronizacji która tam jest zbędna.

Nie wymusiła i nie jest zbędna. To użytkownik decyduje, jak tego użyje. W przykładach
synchronizacja pojawiła się dopiero w ostatnim (6. SSE) i właśnie ten przykład można
napisać inaczej, np. włączając wywołanie akcji HTTP we własną kolejkę zdarzeń.

> Coroutines -> musisz kręcić jakimś server->next()
> Wątki -> musisz synchronizować callbacki z i do bibloteki.

Tak. Np. w bibliotece YAMI4 są dwa poziomy API. Niższy to tzw. core, gdzie trzeba
wołać funkcję agent.do_some_work(). Wyższy to tzw. high-level, gdzie "samo lata".
I zgadnij, czego ludzie używają.

> Ani jedno ani drugie nie jest lepsze.

Zgadza się. Więc jeśli będzie potrzeba, to biblioteka HTTP w wersji eventowej też
powstanie. Ale na razie nie potrzeba.

> GUI (natywne) nie lubi jeśli ktoś komunikuje się z nim przez wątki.

Tu nie ma natywnego GUI.

> Więc jeśli budujesz apliakcję na komputer w którym jest GUI
> natywne, powiedzmy w Gtk i jednocześnie w tle apliakcji pracuje sobie
> Twój web server to właśnie dostałeś w prezencie wątki których wcale byc
> nie musi.

Ale których obecność nie musi być problemem.
Ciekawe - przez 30 lat wszyscy mieli pretensje do C++, że nie ma standardowych
wątków. Teraz ma i jest problem, że są?

> Możliwe że się nie rozumiemy w kwestii GUI. Ja mam na myśli GUI w
> programie w którym ktoś wembedował również Twój HTTP.

A ja progam, który tego klasycznego GUI już nie ma. Ale niech będzie, że ma.

> Dzięki temu
> aplikacja GUIowa, mimo że z wątkami ma 0 wspolnego,

Ja jeszcze nie widziałem takiej aplikacji (pomijam przykłady typu kalkulator z
tutoriala do tegoż GUI).
W aplikacjach, które widziałem, na potrzeby GUI był przeznaczony 1 z N wątków tejże
aplikacji. I było M powodów, żeby właśnie tak zrobić.

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