[RFC] XMPP a desktop (22 stycznia 2005, 16:44:15)
A gdyby zintegrować email, IM i RSS na biurku? Spróbowałem to sobie
wyobrazić. I widzę to tak:
wersja 0.1, 22.01.2005
Rdzeń
Centralną częścią jest programik o roboczej nazwie Connectivity Daemon. Jest on w zasadzie klientem Jabber/XMPP działającym w tle, pełni funkcje dyspozytora wiadomości. Przychodzące krotki <presence/> przekazuje do Galago, natomiast <message> rozdziela, wg. typu, następująco:- chat - jeśli jest włączony program do IM (Psi, GAIM, ekg2?), to przekazuje do tego programu. Jeśli nie - to buforuje (i wyświetla notify - o tym później).
- headline - gdy jest włączony czytnik RSS - przekazuje mu; jeśli nie - dopisuje do spoola tego czytnika. Wady: musi znać format spoola (lub korzystać z nieistniejącej jeszcze specyfikacji freedesktop.org. Pewna duplikacja kodu między czytnikiem a pluginem zapisującym do spoola w CD.
- message czyli zwykłe - lekka zmiana nagłówków i przepuszczenie przez procmaila celem umieszczenia w kolejce poczty użytkownika.
Scenariusz działania
Włączamy komputer i logujemy się. W czasie startu sesji uruchamiany jest Connectivity Daemon.- korzystając z danych w konfiguracji CD łączy się na nasze konto XMPP/Jabber. Zasób (resource) generowany jest na podstawie sesji, np. hostname+$DISPLAY. Status ustawiany jest na niewidoczny (niedostępny w XMPP? co w zamian?).
- serwer XMPP przesyła do nas:
- informacje o obecności osób - CD karmi nimi Galago.
- wiadomości typu headline i message - trafiają one do odpowiednich spooli.
- wiadomości typu chat - wyświelane są wyskakujące informacje o tym, że dana osoba chciała z nami porozmawiać, z datą i godziną, byćmoże zdjęciem osoby i jej aktualnym statusem oraz przyciskiem Chat, otwierającym okienko rozmowy IM. Gdyby takich informacji miałbybyć więcej niż 4 - informacja zbiorcza typu ,,Chcieli z toba rozmawiać Wojtek, Phantom, Monika...'' i przyciskiem do włączania aplikacji IM. Oczywiście wszystkie wiadomości muszą być zachowane w spoolu (archiwum) aplikacji IM, która musi w jakiś sposób informować o nich po włączeniu.
- Użytkownik włącza IM - następuje zmiana statusu z niewidzalnego na na taki jak użytkownik sobie życzy. Ewentualnie - drugie zalogowanie za pośrednictwem CD ale to chyba więcej problemów niż zalet.
Wiadomości
Poczta emailowa ma być wkomponowana w strukturę XMPP, czyli używać go jako środka transportu. Częsciowo jest to już zrobione, vide wpis w joggu Smoka. Zadaniem CD ma być integracja i odpowiednie przekazywanie poczty, więc:- wiadomości przychodzące z jabbera muszą mieć zmieniane adresy nadawcy
na coś typu user%host@xmpp.
not-for-mailinvalid. W takiej formie muszą trafiać do spoola użytkownika (przez procmaila?). - CD musi dostarczać odpowiednik /usr/bin/sendmail którym musi być wysyłana cała poczta. Jeśli poczta wysłana z MUA ma adres nadawcy w formie user%host@xmpp.invalid - dostarczenie jej musi się odbywać na zadany JID.
- w przypadku zwykłej poczty - pierwsza próba dostarczenia również ma się odbyć po XMPP - zakładamy pełną integrację CD u wszystkich. Ewentualnie, jeśli adresat jest w naszej książce adresowej oznaczony ,,chce otrzymywać pocztę XMPP'' lub jest online i za pomocą Entity Capabilities ogłasza, że chce przyjmować pocztę XMPP - tą drogą musi nastąpić wysyłka. Z fallbackiem do SMTP.
- wysyłka wogólnym przypadku następuje do osób, a nie na adresy email. Jeśli jakiś adres XMPP/Email danego odbiorcy nie odpowiada, należy użyć innego spośród podanych w książce adresowej. Z tej samej kategorii adresów oczywiście (Domowy, Praca itp.).
- w przypadku osób używających niektórych klientów zdarza się, że rozmowa nie jest oznaczana jako ,,chat''. Wtedy trafia do skrzynki emailowej. MTA musi wyświetlając wiadomość obok nadawcy wyświetlić jego aktualny status i ikonkę ,,Rozpocznij rozmowę IM'' celem przeniesienia konwersacji na IM. (wymagany jakiś sposób oznaczania danego rozmówcy jako ,,broken'', żeby kolejne wiadomości od niego bez oznaczenia ,,chat'' jednak były traktowane jako takie. Automatyczny sposób).
- kwestia spamu:
- SMTP - znamy i walczymy teraz
- XMPP/Jabber zapewnia, że domena nadawcy działa i jest na niej sprawny serwer XMPP - inaczej nie można wysłac wiadomości (dialback).
RSS
Czytnik RSS nie ściąga rssów sam z serwerów tylko otrzymuje je od CD. Sam Connectivity Daemon ma wtyczkę do parsowania rssów i programowania ich na desktopie albo robi to serwer. Ideałem byłoby łatwe zintegrowanie PublishSubscribe.Wiele kont
tutaj sprawa jest trudniejsza. Można albo:- zrezygnować ze wsparcia dla wielu kont pozostawiający JID jako single internet identity - raczej niewykonalne.
- zintegrować wiele kont w CD, dając wybór podobny jak jest w programach pocztowych - przy wysyłaniu wiadomości czy zaczynaniu rozmowy rozwijana lista ze zdefiniowanymi kontami i możliwośc wyboru.
Wymagania wobec serwerów
- SMTP/pocztowy - przychodzące maile rewrite+pchnięcie do XMPP
- XMPP - przechowywanie wiadomości bez ich utraty
Usługi typy Jogger
Możliwość skonfigurowania dwóch rodzajów powiadomień:- obecne - przychodzące jako ,,chat''
- powiadomienia skladające się z poprawnego RSS, przychodzące jako ,,headline'' i renderowane przez czytnik RSS
- idealne - PubSub, renderowane przez czytnik RSS
Brzmi doprawdy cudownie, choć mocno idyllicznie. Za ile lat, jeśli wogóle taki scenariusz mógłby sie sprawdzić?
W chwili obecniej _bardzo_ ciężko jest kogokolwiek (użytkownika, admina, whoever) z czegoś, czego używa na coś nowego, niezaleznie od tego, jak dobra by taka nowość nie była.