xime: API, COM, XCOM...

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

Ostatnio zacząłem trochę pracować nad restrukturyzacją modułów, o czym wspominałem w jednej z poprzednich notek. Wydaje się, że sprawa wygląda dosyć prosto - pomyśleć co aplikacja potrzebuje od modułów i odpowiednio dostosować ich interfejs. No, ale prócz tego warto od razu pomyśleć też nad tym co będzie dostępne w API i wziąć to również pod uwagę. I tak doszedłem do odwlekanej kwestii API.

Na początku myślałem, aby API miało budowę i strukturę podobną do API udostępnianego w mirandzie i tlenie. System ten wydawał się prawie idealny, ale postanowiłem to zmienić. Mając ostatnio styczność z COM i XPCOM uznałem, że wykorzystanie zalet i możliwości tych “technologii” będzie lepszym wyborem. Głównie dlatego, że będzie obiektowe, ale nie narzucające żadnych ograniczeń co do używanego języka. Nie chciałem ograniczać twórców wtyczek do jednego słusznego języka i technologii, a opierając API na czymś podobnym do COM, gdzie liczy się binarna zgodność, mamy wszystko co chciałem - komponentowo-obiektowy niezależny system.

Fajnie byłoby wykorzystać coś gotowego. Niestety COM działa “względem” systemu i ciężko będzie się tym bawić i hostować w mojej aplikacji. Jest crossplatformowy odpowiednik - XPCOM, używany przez Mozillę w swoich produktach. Ciekawy, ale trochę zbyt przeładowany i rozbudowany jak na mój gust, wolałbym coś mniejszego i prostszego.

No cóż, pozostaje zrobienie czegoś swojego, małego, lekkiego i bardzo minimalistycznego. Zatem chyba startuję z kolejnym projektem o kodowej nazwie XCOM. Projekt będę rozwijał równolegle, bo najlepsze efekty uzyskam wtedy, gdy będę na bieżąco korzystał z tego co tworzę. Czemu osobny projekt, a nie część xime? Bo na pewno zostanie wykorzystany w innych projektach i aplikacjach. O samym projekcie może wkrótce napiszę coś na swoim devblogu.

Odnośnie samego pomysłu i wykorzystania COM-a w programie. Na pewno nie będę chciał popełnić błędu, na który natknęli się twórcy Mozilli, choć od jakiegoś czasu planują to poprawić (DeCOMtamination). Między innymi dlatego właśnie Apple oparło WebKita na KHTML-u zamiast na Gecko. Wracając do wątku, chodzi o to, aby wewnętrznie aplikacja, moduły i cała reszta nie korzystała z XCOM-a i interfejsów COM-owych, a używała natywne bezpośrednie odwołania do interfejsów i klas. Cała implementacja interfejsów COM-owych będzie stworzona tylko na potrzeby API do wtyczek. Mówiąc kolokwialnie, mostek między wtyczkami i aplikacją będzie opakowany w XCOM. Uniknę w ten sposób dosyć wielkiego spowolnienia i zaniżenia efektywności, szczególnie w krytycznych elementach aplikacji.