xime: Modularność i koncepcja wtyczek

Ta notatka jest częścią serii xime. Zapoznaj się z pozostałymi wpisami.

O tym, co to wtyczka i czym może stać się dla użytkownika programu, można dowiedzieć się na Wikipedii:

Wtyczka (ang. plug-in) to dodatek do istniejącego programu rozszerzający jego możliwości lub automatyzujący żmudne czynności.

Wtyczka może stać się źródłem dodatkowej, dowolnej funkcjonalności, jakiej zabrakło w głównym programie. Oczywiście zdarza się, tak jak w naszym przypadku, że to właśnie wtyczki odpowiadają za całą (lub prawie całą) funkcjonalność programu, a bez nich sam program staje się bezużyteczny.

Nie ma rzeczy doskonałych, każda rzecz posiada jakieś zalety i wady, także modułowość i system wtyczek.

Jedną z głównych zalet jest modularność, gdzie system wtyczek zapewnia dodatkową funkcjonalność rozszerzającą program. Dzięki takiemu podejściu użytkownik może dowolnie konfigurować funkcje, wygląd i zachowanie programu. Zyskujemy przez to oszczędność zasobów i szybkość działania. Użytkownik sam zarządza wtyczkami i ładowana jest tylko ta funkcjonalność jakiej potrzebuje.

Kolejną zaletą jest rozproszenie prac nad projektem. Autorzy programu mogą zając się jego rozwojem, a dzięki rozbudowanemu API niezależni programiści mogą w tym czasie tworzyć i rozwijać wtyczki, dodając nową funkcjonalność jakiej społeczność użytkowników może się domagać.

Jestem świadomy tego, że zapewne większość wtyczek, przynajmniej w początkowej fazie, będzie mojego autorstwa.

Może nie istnieją jakieś wielkie wady w koncepcji wtyczek w naszym projekcie, ale za to pojawia się kilka problemów.

Jako, że jednym z głównych cech naszego komunikatora jest wieloplatformowość, to właśnie ona jest źródłem kilku problemów. Chodzi o GUI we wtyczkach. Sama aplikacja korzysta z wxWidgets, a API w domyśle ma być niezależne od wszelkich bibliotek i języka, więc GUI może sprawiać problemy. Dobrym pomysłem może być wykorzystanie XML-owego formatu opisu okien, dialogów i innych zasobów, w naszym przypadku systemu XRC (XML-based resource system).

W takim wypadku pozostanie do rozwiązania kwestia obsługi tak utworzonego okna. Oczywiście będzie możliwość wykorzystania we wtyczkach biblioteki wxWidgets, gdy komuś na tym będzie zależało. W Windowsowej wersji aplikacja będzie rozpowszechniana ze stosowną biblioteką DLL, a deweloperzy będą mieli dostęp do pliku lib.

Inną obawą związaną z cross-platformowością i wtyczkami jest to, że twórcy wtyczek mogą olewać zadbanie o wieloplatformowość. Idealnym rozwiązaniem byłoby pisanie takiego kodu, aby przenośność i wydanie wersji na inne systemy ograniczałoby się do przekompilowania kodu na innym systemie. Taką możliwość chyba będą mieli tylko Ci deweloperzy, którzy wykorzystają wxWidgets w swoich pracach, a nie każdy przecież musi z niej korzystać.

Odnośnie tematu wtyczek nasuwają mi się jeszcze dwie sprawy.

Okno ustawień. Czy pluginy będą mogły dodawać swoje zakładki z opcjami w dowolne miejsce w tym oknie? Czy w dowolnej gałęzi okna będą mogły dodać swoją zakładkę i zarządzać istniejącymi? A może lepiej po prostu stworzyć jedną gałąź dla wtyczek i tam dodawać? Pierwsza opcja daje większą swobodę i możliwości, ale w jakimś stopniu nie jest bezpieczna oraz może wprowadzać zamieszanie i zamęt wśród użytkowników. Druga natomiast trochę ogranicza…

Obsługa sieci we wtyczkach. Jak już napisałem, obsługę poszczególnych sieci będą zapewniać wtyczki. Nasuwa się pytanie, czy niskopoziomowa obsługa sieci powinna być zaimplementowana w core? Wtedy połączeniem, wysyłaniem i odbieraniem danych opiekowałby się sam program, a dane wędrowałyby do wtyczki. Ciekawe rozwiązanie, ale pojawia się problem z bibliotekami do obsługi sieci/protokołów komunikacyjnych, bo przeważnie taka niskopoziomowa obsługa jest w nich zaimplementowana. W przypadku, kiedy sam pogram zarządzałby połączeniami zredukowałaby się liczba wszelakich wątków i można byłoby połączenia obsługiwać asynchronicznie.

Ale te kwestie już bardziej dotyczą samego API, o którym za jakiś czas sobie “porozmawiamy” ;)