Opisane obok projekty na linii czasowej:

KHTML (KDE) - 1998

SQLite - 2000

WebKit - 2003 WebKit.org - 2005

Google Gears - 2007

Google Chrome - 2008

Korzenie

Związki z KDE nie kończą się na Gears. Google Chrome bazuje na silniku obsługi HTML - WebKit. Na WebKit zaś składają się przede wszystkim:

• silnik HTML - WebCore - będący wersją (forkiem) zmodyfikowanego oryginalnie przez Apple dla Mac OS X silnika KHTML z KDE


• silnik obsługi Java Script - JavaScriptCore - będącego wersją (forkiem) silnika KJS z KDE

Technikalia

Idea stosowania wielu procesów składających się na jeden program, tak by podnieść niezawodność tegoż oraz zmniejszyć opóźnienia reakcji na działanie użytkownika, nie jest nowa. Systemy operacyjne (nie licząc m.in. prostych systemów wbudowanych oraz DOS i Windows włącznie z Me) właśnie w ten sposób izolują wzajemnie od siebie uruchamiane programy. Zabieg ten nie jest jednak chętnie stosowany w aplikacjach desktopowych (serwery to inna bajka) z uwagi na większą złożoność kodu źródłowego pisanego z myślą o wieloprocesowości czy wielowątkowości.

W KDE, dzięki technikom oferowanym przez Qt 4, Qt Concurrent, pamięć dzielona, i wygodne narzędzia do obsługi wątków, można liczyć na to, że coraz więcej aplikacji będzie stawało się wielowątkowymi czy wieloprocesowymi. Pod wieloma względami środowisko KDE, jako pulpit jest wieloprocesowe, bowiem składa się z wielu usług/demonów, począwszy od systemu cache dla konfiguracji (KSyCoCa), przez demona komunikacji międzyprocesowej D-Bus, aż po cache dla grafik wektorowych (np. do gier) oraz ikon.

Wiadomo, że do nieunikania mnogości demonów zachęca sama filozofia Unixa. Nieuważny obserwator zdziwiłby się też widząc liczbę dodatkowych procesów działających także w nowszych wersjach Windows. Do takich a nie innych decyzji projektowych zachęcają też mocne komputery i zoptymalizowane systemy operacyjne (Linux/Unix w optymalizacji bardziej stawia na procesy, Windows na wątki). Nie mają już one problemu z kosztem przełączania kontekstu między procesami.

Zgrzyty

Teraz łyżka dziegciu. Można sobie wyobrazić dziś zwykłą ludzką gorycz autorów KHTML i KJS. Apple przez lata nie wspominał o KHTML zbyt intensywnie. Póki co, nie kwapi się tego także Google. Z drugiej strony Aaron stwierdził dziś, że aktywne propozycje z jego strony dotyczące promowania KHTML lata temu nie spotykały się z ciepłym przyjęciem autorów KHTML/KJS. Projekt był traktowany jako swojego rodzaju wewnętrzny dział i był raczej zorientowany na programistów a nie użytkowników.

Cóż, sam na tegorocznym Akademy nieopatrznie wypowiadając słowo WebKit w towarzystwie kogoś związanego z KHTML/KJS, czułem niezręczną ciszę.... A wypowiadać musiałem, gdyż w rozwojowej gałęzi Kexi z premedytacją użyłem WebKit do wykonania kontrowersyjnej dla niektórych rzeczy (jeszcze nie opublikowanej), a poza tym kolejne wersje osiemsetdziesiątek rozdanych nam przez Nokię, mają podobno być napędzane WebKitem.

Parę wniosków

Nowinkę uważam za pomyślną. Qt 4.4 zawiera nadbudowę dla WebKit, więc nie jest to dla KDE "ciało obce" także z punktu widzenia programisty. Istnienie Chrome może pomóc w usunięciu pewnych problemów z działaniem usług webowych Google pod Konquerorem.

Pod względem konkurencji, WebKit i KHTML można uważać za jeden front, w opozycji do frontu "Mozillowatych". Popularność WebKit zabiera "rynek" Mozilli, choć jeszcze bardziej ciekawe jest to, że Google dopiero co odnowiło, będącą po części opłatą za swoistą powierzchnię reklamową, umowę z Mozillą, przynoszącą jej 85% przychodów.

Na froncie marketingowym słychać zaś pomysły, by promować WebKit jako jeden z filarów KDE, nawet gdy technicznie stosowany jest tu oryginalny KHTML/KJS a nie fork. Do popularności Plasmy tym ostatnim daleko i chyba coraz dalej, przede wszystkim dlatego, że jak już wspomniałem, poległy one pod względem marketingowym.

Zobaczymy co się od strony organizacji poszczególnych projektów oraz ich relacji do KDE. WebKit i Chrome są otwartymi projektami. Pytanie, czy będą otwartymi w stylu OpenOffice.org czy choćby Qt (otwartość formalna, a programiści w większości nie są ze społeczności lecz z jednej firmy - np. SUN, Nokia), czy też otwartymi w stylu KOffice/KDE (produkt tworzony przez społeczność, a otwartość także w sensie wyboru strategii działania i podejmowania decyzji technicznych).