[ekg2-devel] Wysyłanie powiadomień o pisaniu - podsumowanie implementacji

[Michał Górny]

----- Forwarded message from Michał Górny <peres w peres.int.pl> -----

Date: Wed, 29 Aug 2007 22:46:29 +0200
From: Michał Górny <peres w peres.int.pl>
To: ekg2-devel w lists.ziew.org
Subject: Wysyłanie powiadomień o pisaniu - podsumowanie implementacji
Message-ID: <20070829204629.GA2502 w peres.cccp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.16 (2007-06-09)
Status: RO
Content-Length: 3104
Lines: 62


Ogólnie starałem się całość zaimplementować jak najbardziej
uniwersalnie, na wypadek gdybyśmy zdecydowali się np. dodać wsparcie AQQ
— w tej sytuacji wysyłanie powiadomień w formacie tego komunikatora
(z liczbą wpisanych znaków) nie będzie wymagało dodatkowych zmian w API.

Zasadniczo całość zaimplementowana jest po stronie wtyczek, aby uniknać
niepotrzebnych komplikacji w core i jednocześnie zapewnić przyszłą
rozszerzalność. Obecny kod zakłada bowiem, że w danej chwili zdarzenie
„typing” może być aktywne tylko i wyłącznie dla jednej osoby (wysłanie
do innej powoduje anulowanie u poprzedniej). Podjąłem taką decyzję
z dosyć jasnego względu, iż w ncurses prompt jest wspólny, niezależnie
od aktualnie otwartego okienka.

Większość szczegółów odnośnie reagowania zgadza się z moim pierwszym
e-mailem na ten temat. Wszystko jest konfigurowane trzema zmiennymi
wtyczki ncurses. 'ncurses_typing_interval' określa, jak często ncurses
aktualizuje dane nt. zapisanych w prompcie danych (a więc minimalny
odstęp pomiędzy poszczególnymi wysłaniami, jeśli użytkownik coś pisze).

'ncurses_typing_timeout' określa po jakim czasie od zaprzestania
wprowadzania zmian żądanie pisania ma być anulowane. Podobna zmienna z
'_empty' określa alternatywny czas dla sytuacji, kiedy użytkownik
wykasuje cały wpisany tekst. Jeśli drugie nie jest zdefiniowane,
używanyh jest czas z pierwszego. Jeśli obie nie są — anulowanie następuje
natychmiast w momencie wyczyszczenia; w tej sytuacji również nie
następuje anulowanie pisania przy pozostawieniu wiadomości w oknie (np.
odejście od komputera).

Oprócz tego, anulowanie następuje w momencie zamknięcia okna (konieczne,
aby uniknąć odwołań do zwolnionego okna). No i oczywiście przy
rozpoczęciu pisania w innym oknie.

Parametry query:
- char**	- UID sesji,
- char**	- UID rozmówcy,
- int*		- liczba znaków wpisana w prompcie (0 = anulowanie),
- int*		- czy pierwsze żądanie z kolei (CZYTAJ NIŻEJ!).

Ostatni argument ma na celu łatwe rozróżnianie pomiędzy protokołami
operującymi jedynie na ogólnym stanie pisze/nie pisze (jabber), a tymi
operującymi na konkretnej liczbie znaków (aqq). Jeśli zmienna ta jest
ustawiona, oznacza to, że nastąpiła zmiana celu/wiadomości, w każdym
razie — konkretna zmiana. Zero zaś oznacza, że zmieniła się jedynie
liczba znaków (i jeśli na owej liczbie i tak nie operujemy, to nie warto
nic wysyłać).

Dzięki temu np. jabber nie musi ze swojej strony dokładać szczególnych
starań, by przy zmianie liczby wpisanych znaków powiadomienie nie było
(bezsensownie) wysyłane ponownie. Zaś np. takie AQQ będzie za każdym razem
aktualizować licznik.

Od razu zaimplementowałem również przechwytywanie tego query po stronie
jabbera i proste wysyłanie odpowiedniego powiadomienia. Jednak
zaimplementowałem je jedynie dla XEP-0022. Wsparcie dla chatstates może
później (tyle że musielibyśmy je wprowadzić szerzej w jabberze).

-- 
Pozdrawiam,
Michał Górny
<peres w peres.int.pl>
<xmpp:mgorny w wafel.com>

----- End forwarded message -----