Dnia 2012-07-02, pon o godzinie 23:31 +0200, Tomasz Wasilczyk pisze: > Zrobiłem bardzo wstępną implementację [1], którą podpiąłem na sztywno > do połączeń http - na razie bez żadnej konfiguracji, taki > proof-of-concept. > > Działa ona w ten sposób, że najpierw zlecamy nawiązanie połączenia za > pomocą gg_proxy_default_connect (docelowo będzie to jeden z możliwych > rodzajów funkcji nawiązującej połączenia), następnie obserwujemy > uzyskany file descriptor i sprawdzamy stan za pomocą > gg_proxy_default_watch. Jeżeli ta ostatnia funkcja zwróci coś innego > niż GG_PROXY_RESULT_CONNECTING, to już mamy rezultat (sukces lub > powodzenie). > > Proszę o komentarze. Część tego kodu jest bardzo "tymczasowa", ale > oddaje możliwy sposób na takie nawiązywanie połączeń.
Nie podoba mi się dodawanie kolejnej maszyny stanów. Być może nie do końca rozumiem, co jest tymczasowe, co docelowe, ale zakładam, że to, co wrzuciłeś do libgadu.h tymczasowe nie jest. To, co proponowałeś wcześniej, wydawało się w zupełności wystarczające -- jeśli ktoś chce proxy, podaje wskaźnik na funkcje łączącą się, a my czekamy na wynik. Monitorowanie deskryptorów własnej funkcji łączącej mocno komplikuje. Podobnie są zrobione własne resolvery -- nie dajemy dostępu do naszej pętli zdarzeń, czekamy tylko na wynik. Nawet gdyby ktoś chciał użyć własnego resolvera opartego na adns, i tak musiałby stworzyć nowy wątek. Nie powinno być to problemem nawet w jednowątkowych aplikacjach typu ekg -- wystarczyłoby we własnej pętli zdarzeń monitorować co tylko się chce. I przepraszam, że tak późno, ale mam teraz tyle na głowie, że gdy już na chwilę siadam do komputera, to nie pamiętam, jak się nazywam. Pozdr, Wojtek _______________________________________________ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
