niedziela, 17 października 2010

Telepathy, a sprawa KDE

Fot. http://grundleborg.wordpress.com/
Czym jest Telepathy, najkrócej można powiedzieć, że jest to framework pozwalający na dodanie do różnych programów funkcji pozwalających na swobodną komunikacje pomiędzy nimi poprzez internet, a ściślej protokół IP. Krótko mówiąc Telepathy to taki komunikator, tylko zarządzany z poziomu pulpitu i programów umieszczonych w systemie. Jeszcze mało jasne? No to może dalsza część artykułu więcej wyjaśni.

Telepathy od jakiegoś czasu rozgościło się w środowisku GNOME. Właściwie wielu użytkowników GNOME nawet nie zauważyło jego obecności, dla wielu była to po prostu wymiana jednego komunikatora (Pidgin) na drugi (Empathy). Takie myślenie jednak prowadzi w ślepy zaułek. Empathy nie jest tak właściwie komunikatorem w pełnym tego słowa znaczeniu, jest raczej frontendem graficznym dla Telepathy, dzięki któremu możemy dodać nowe kontakty, przypisać im avatary itp. Obsługa protokołów (Gadu Gadu, Tlen i inne) należy jednak do telepathy i to do niego przypisywane są poszczególne funkcje tych protokołów. Ale Telepathy to nie tylko obsługa wymiany informacji pomiędzy użytkownikami. Protokół IP pozwala także na transfer plików, rozmowy głosowe (VoIP) i video i wiele innych. Oczywiście wszystko zależy od tego czy dany protokół posiada takie funkcje.

Wyższość Telepathy nad monolitycznymi komunikatorami przejawia się w tym, że potrafi stosować komunikacje także pomiędzy programami, które nie muszą wcale służyć do standardowej wymiany informacji jaką posiadają komunikatory. Przykładowo chcemy zagrać w jakąś grę z pakietu gnome-games, lub kdegames z kolegą, którego mamy w kontaktach, program wysyła wtedy informację do niego o możliwości takiej rozgrywki i po zaakceptowaniu mamy już multiplayer. Proste prawda! Pozostaje tylko dopisać odpowiedni plugin do takiej gry, a Telepathy zajmie się już sama obsługą protokołu i np. takimi szczegółami jak firewall.

Fot. http://grundleborg.wordpress.com/

W GNOME świetny przykład wykorzystania Telepathy stanowi jeszcze aplet stanu użytkownika (czy jak to się tam nazywa ?), który ma za zadanie informować inne osoby z naszych kontaktów, czy aktualnie znajdujemy się przy komputerze i czy nie jesteśmy zajęci. Niestety od jakiegoś czasu nie używam już tego środowiska także nie podobam więcej szczegółów na temat wykorzystania przez nie tego frameworka. Przejdźmy więc na własne podwórko.

Wersja dla KDE SC rodzi się już od dawna, jednak chyba nie prędko zobaczymy Telpathy-KDE na naszych pulpitach. Stan prac nad frameworkiem sugeruje, że być może część funkcji będzie już dostępna w KDE SC 4.7, a najdalej w 4.8, gdyż będzie ona już korzystała z Qt w wersji 4.8, która pozwoli na lepszą współpracę z D-Bus. Jednak już teraz wśród szczątkowych informacji udzielanych przez deweloperów można nakreślić kształt współpracy tego frameworka ze środowiskiem.

Fot. Dr. Danz's blog

Przede wszystkim zapomnijcie o Kopete. Nie jest pewne, kiedy i czy w ogóle zniknie ten program z zestawu aplikacji KDE SC. Gdzieś czytałem o pracy nad pluginem, który pozwalałby Kopete korzystać z frameworka. Jednak deweloperzy uważają, że ten komunikator jest przerośnięty w funkcje, które pokrywają się z analogicznymi możliwościami Telepathy-KDE, w związku z czym nie ma sensu ich dublowania. Kopete zastąpi lista kontaktów, za pomocą której programy będą się kontaktowały z naszymi znajomymi. Aplkacja ta nie będzie zresztą prawie w ogóle wykorzystywana przez użytkownika, oprócz oczywistych funkcji jak dodawanie nowych kontaktów i ich konfiguracja.

O naszej obecności będzie informował plasmoid, który prawdopodobnie zagnieździ się w tacce systemowej. Za jego pomocą będziemy mogli także zmienić nasz status.

Za komunikację pomiędzy użytkownikami odpowiedzialne będą dwie samodzielne aplikacje Chat Window i VoIP Call Window ( nie mają one jeszcze oficjalnych nazw, więc wykorzystałem tu nazewnictwo oparte na funkcjach tych programów). Pierwszy program służy do przekazywania wiadomości tekstowych, drugi rozmów głosowych. Będą one uruchamiana i automatycznie łączyły się z D-Bus w momencie zainicjowania rozmowy. Podobną funkcję posiada obecnie Kopete, które łączy się z protokołem Skype we własnym oknie chatu, jednak klient Skype musi być i tak w tym momencie uruchomiony.

Fot. Dr. Danz's blog

Telepathy-KDE będzie posiadało także trzy rodzaje demonów działających w tle. Demon zatwierdzający (an approver daemon). którego zadaniem jest nasłuchiwanie przychodzących kanałów. W momencie kiedy ktoś zainicjuje z nami rozmowę, będzie chciał zagrać, lub zażąda współdzielenia pulpity, zostaniemy wtedy poinformowanie przez okno powiadomień (knotify), wraz z funkcjami pozwalającymi na akceptację lub rezygnację.Program do transferu plików (file transfer daemon) - zostanie automatycznie uruchomiony w momencie zainicjowania transferu plików do kontaktu, z którym jesteśmy w trakcie chatu lub rozmowy video. Funkcja zainicjowania transferu plików będzie dostępna w oknie rozmowy. Demon integracji z Nepomukiem (nepomuk integration daemon) - jego zadaniem będzie możliwość tworzenia metakontaktów poprzez integrację naszych kontaktów, w bazie Nepomuka, z kontaktami znajdującymi się np. w zasobach Akonadi.

Przyszłość komunikacji w KDE rysuje się coraz wyraziście i muszę przyznać, że świetnie wpisuje się w cały charakter współpracy pomiędzy programami KDE SC. Niestety w obecnej formie budzi jeszcze wiele niedomówień. Przede wszystkim wiele emocji budzi sprawa Kopete. Będzie ono pewnie przez jakiś czas dostępne w KDE ale nie wiadomo, czy są jakiekolwiek szanse na współprace z Telepathy, a deweloperzy nie chcą się tym na razie zajmować. Zresztą według ich zapewnień Telepathy obsługuje w tej chwili znacznie więcej protokołów niż Kopete w tym IRC, który znikł z tego programu po transformacji do KDE 4. Dużo mówi się też o współpracy ze Skype, którego protokół jest zamknięty, ale autorzy mają nadzieję zbudować własne połączenie przy pomocy udostępnionego niedawno przez deweloperów Skype API.

Dyskusyjne jest też wykorzystanie przez VoIP Call Window, który jest budowany na bazie programu KCall wykorzystującego GStreamera. Przy tak dużym projekcie mającym wpływ na kształt wielu funkcji środowiska dyskusyjne jest wykorzystanie jednocześnie dwóch frameworków tego typu na jednej platformie, tym bardziej, że GStreamer jest bardzo GNOMO-lubny jeśli chodzi o zależności. Deweloperzy Telepathy tłumaczą jednak, że jest on bardziej rozwojowy od Xine, którego rozwój według nich stoi w miejscu.

Pozostaje nam więc czekać na zakończenie prac bo według mnie warto.

Źródła informacji:
http://gkiagia.wordpress.com/
http://gnomejournal.org/article/86/telepathy-overview
http://blogs.fsfe.org/drdanz/
http://grundleborg.wordpress.com/

=-=-=-=-=
Powered by Blogilo