March 10, 2005

KDE 的 IPC 實做該採用 D-Bus?

莎士比亞有句名言:"To be, or not to be: that is the question." (Hamlet 3/1),而 KDE 開發者 Mathieu Chouinard 在他的 blog [The "Foie Gras" syndrom or the force fed technology syndrom] 裡面的敘述,也讓我們有這種感覺。

KDE 2 所引入的眾多技術,奠定 KDE 日後卓越發展的基礎,感謝莊明哲前輩的大作《KDE2 技術開發》(終於拿到親筆簽名了,參考 [首度 KDE@Taiwan 使用者聚會圓滿落幕],感謝前輩的加持)。在這本大作裡頭有提到 KDE 的 IPC (Inter-Processs Communication) 技術變遷,在 KDE 1.x 時代,曾經有一組人馬試著採用 CORBA 作為 IPC 與 Desktop Object Model,但是實際測試的結果,發現 CORBA 實在太複雜了,難以掌控,在 KDE cvs repository 還保有 [過去嘗試 CORBA 的遺跡]。

而儘管 GNOME 陣營採用 CORBA 作為 Object Model,但是卻沒有使用其 IPC 設計,並且也只使用 CORBA 最小的實做 Mico 的部份功能,那麼,KDE 2 最後採用什麼技術呢?答案是自己開發一套,針對桌面環境需求,開發出 DCOP (Desktop COmmunication Protocol),每次提到這個典故,都不由自主佩服 KDE Developers 當時的氣度與勇氣。

在 2000 年,KDE 與 GNOME 開發者共同釋出善意,開啟了 FreeDesktop.org 的計畫,促進桌面系統的標準化,以及加強兩大系統的交互運作,D-Bus 算是這樣訴求的產物,目前 GNOME 與 Qt4 都已經正式支援了,而 KDE 陣營也傾向採用 D-Bus 作為 IPC 基礎。然而,D-Bus 仍然是相當新的設計,很多 API 也才剛邁向穩定,這點在之前的 blog [D-Bus 邁向 1.0 之路] 有提及。

Mathieu Chouinard 提出 DCOP 發展的可能性:
1) leave it in the current state and pray that nothing break
2) reimplement libICE
3) reimplement DCOP using another mechanism like shared memory
4) ditch dcop and using something else

而在四個選擇中,Mathieu 的看法如下:


    I personnaly prefers the third option because I don’t need a networked ipc 99.999999% of the time and if we really need to interoperate with gnome let just use a bridge. And if people prefers to go with option 4 why use D-BUS? why not use DCE which is now Opensource and which will enable us to interoperate with more systems.

目前的 DCOP 相當有效率也穩定,相對來說,D-Bus 有彈性但也需要更多歷練,究竟 KDE Team 要如何抉擇呢?本 blog 後續的評論提供我們許多重要的參考。

由 jserv 發表於 March 10, 2005 01:23 PM
迴響

這一期(2月應該是上一期)的Linux Jounal 有專文說明D-BUS喔。

checko 發表於 March 11, 2005 08:15 AM