Dnia 2012-06-08, pią o godzinie 11:18 +0200, Tomasz Wasilczyk pisze: > chcę zaimplementować obsługę proxy dla gadu-gadu w Pidginie. Problem w tym, > że: > - ustawienia proxy w libgadu są globalne dla wszystkich połączeń > - libgadu nie obsługuje (przynajmniej wg. dokumentacji) wszystkich > rodzajów proxy, które obsługuje Pidgin
Najwyraźniej nikomu do tej pory nie był potrzebny inny rodzaj proxy. To, co jest, było dodawane daaawno temu, kiedy pewnie nawet się nie śniło o więcej niż jednej sesji :) > Najlepiej by było, jakby libgadu udostępniało możliwość rejestracji > własnej funkcji nawiązującej połączenia, tak jak to jest zrobione z > zapytaniami DNS (gg_global_set_custom_resolver). Można by to było > łatwo zrobić, modyfikując funkcję gg_connect (dlaczego właściwie to > jest deprecated?), ale ona nie otrzymuje informacji o sesji, w ramach > której ma zostać użyta. Jest "deprecated" z punktu widzenia API. Nie chcemy, żeby aplikacje jej używały i przy którymś podbiciu wersji ABI przestanie być widoczna poza biblioteką. Pytanie tylko, czego potrzebujesz ze struktury sesji do połączenia. Pidgin ma jakieś szczególne wymagania przy połączeniach przez proxy? Bo jeśli zrobić wersję gg_connect(), która dostaje wskaźnik na gg_session, to co z połączeniami HTTP czy bezpośrednimi? > Prosiłbym o podpowiedź, co mogę zrobić w tym kierunku. Chętnie > zaimplementuję obsługę wspomnianych ficzerów, moja propozycja: > - nowa funkcja gg_connect2 lub gg_connect_proxy, nawiązująca > połączenie TCP (niezależnie, czy przez proxy czy nie, po prostu > nawiązuje) z takimi samymi parametrami co gg_connect + wskaźnik na > strukturę sesji > - przeniesienie gg_connect do obsolete, implementacja poprzez > wywołanie gg_connect_proxy z parametrem struktury sesji równym NULL > - poprawienie wszystkich miejsc, w których jest używane gg_connect > tak, żeby przekazywały też strukturę sesji Ogólnie to dobry kierunek, zakładając, że nie będzie to gg_session (patrz wyżej). Dobrze by było też, gdyby nowe funkcje manipulujące parametrami proxy dla sesji zaczynały się od prefiksu gg_session_, tak jak te dla resolverów, ale to najmniejszy problem i łatwo poprawić nie wywracając do góry nogami wszystkiego. > Rozwiązało by to chyba też problem opisany w dokumentacji, że serwer > pośredniczący nie jest wykorzystywany dla połączeń bezpośrednich. O tak, tylko dobrze by było dodać jakąś opcję, która mówi, czy serwer proxy ma być wykorzystywany do połączeń bezpośrednich, czy nie. Jeśli ktoś używa tego do przesyłania plików w sieci wewnętrznej, powinien móc się łączyć... no... bezpośrednio? ;) Pozdr, Wojtek _______________________________________________ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
