Jakub Zawadzki napisał(a): > Pytanie do Wojtka: commitujemy/ nie commitujemy? (Tak wiem, niby mam > dostep do CVS, i dostalem zgode, ALE) > (...)
Mam w końcu trochę czasu w weekend, więc zabrałem się za zrozumienie i uporządkowanie Twojego patcha. Skoro i tak nie musimy się trzymać kurczowo starego API, które nijak nie pasuje do nowego sposobu przesyłania plików, to dlaczego nie zrobić tego porządnie, od nowa? Podejście do sprawy przy starym DCC jest beznadziejne, wymaga reakcji na pół tuzina zdarzeń, wywoływania wielu funkcji, a ja nawet nie potrafię teraz tego uzasadnić. Dlatego miło by było, gdyby scenariusz wysyłania wyglądał tak: 1. Klient wywołuje gg_dcc7_send_file(), podając wskaźnik na sesję, nazwę pliku i ewentualnie hash. Funkcja automagicznie dopisze nowe połączenie do listy w struct gg_session i wyśle do serwera żądanie przyznania identyfikatora. Przy okazji od razu przygotuje sobie wszystkie informacje o pliku, takie jak rozmiar, hash (jeśli klient nie podał), żeby mieć co wysłać w odpowiednich pakietach. Oczywiście przydałby się wariant funkcji, która dostaje deskryptor, rozmiar i hash, żeby klient mógł podawać dane przez potok, gniazdo czy cokolwiek innego mu się zamarzy, ale to można zrobić później. 2. Po odebraniu nowego identyfikatora, biblioteka szuka na liście połączeń DCC przypisanych do sesji takiego, które czeka na identyfikator, zapamiętuje go i wysyła pakiet GG_DCC7_NEW. Klient przecież nie musi o tym wiedzieć. 3. Po odebraniu pakietu GG_DCC7_ACCEPT, biblioteka nadal nic nie robi, tylko zapamiętuje offset i czeka na GG_DCC7_INFO. Nie ma sensu zawracać głowy klientowi, skoro i tak jeszcze nie możemy się połączyć (chyba że DCC 7.x obsługuje połączenia zwrotne, to co innego). Dopiero po odebraniu GG_DCC7_INFO przekazuje zdarzenie GG_EVENT_DCC7_ACCEPT. Tutaj przydałaby się jakaś flaga, która domyślnie powoduje automagiczne połączenie się z drugą stroną, ale gdyby klient chciał zweryfikować poprawność adresu (np. żeby uniknąć czegoś w stylu FTP bounce), niech biblioteka poczeka na decyzję z góry. 4. Biblioteka radośnie łączy się z drugą stroną i przesyła plik. W najlepszym przypadku wszystko ograniczyło się do wywołania _jednej_ funkcji (nie licząc tych od zwalniania zasobów) i obserwowania zdarzeń, żeby uaktualnić GUI. Dzięki takiemu podejściu odpada konieczność wywoływania callbacków, żeby dowiedzieć się, którym połączeniem jest zwiazany identyfikator. Zwolnianie struktury gg_dcc7 spowoduje usunięcie z listy, żeby przypadkiem zaległe zdarzenia nie spowodowały odwołań do nieistniejących struktur. Odbieranie nie wymaga już takiego zachodu, bo dostajemy od serwera pakiet z informacją o żądaniu, które akceptujemy albo odrzucami i tyle. Połączeń głosowych jeszcze nie ruszałem. W każdym razie zacząłem już porządkować i przerabiać Twój kod, żeby dało się obsługiwać połączenia bezpośrednie tak jak w opisie. Dzięki temu implementacja nowego protokołu powinna być zupełnie bezbolesna. Na tyle, że w zasadzie sam mogę przygotować patcha dla ekg. Co o tym sądzisz? Co o tym sądzi reszta zainteresowanych? w. _______________________________________________ libgadu-devel mailing list [email protected] http://lists.ziew.org/mailman/listinfo/libgadu-devel
