那些KDE中的技術(二)Akonadi

KDE 是一個強大的圖形桌面環境,各項關於 KDE 使用上的問題或討論歡迎在此提出。

版主: AceLan, Franklin

那些KDE中的技術(二)Akonadi

文章訪客 » 週四 12月 16, 2010 8:28 pm

這同樣也是一個備受爭議的玩意。尤其是它還和Nepomuk攪到一起,讓很多人更加不滿意。

先說說它是個什麼東西。簡單說來就是一個個人資訊管理框架,名稱象徵迦南神話中代表公正的預言女神。它的目標是實現一個跨桌面的個人資訊管理的框架。可以參見下圖:

什麼,你沒有看錯,計畫裡面是有Gnome的,雖然我並不清楚Gnome方面是完全沒有動作呢還是怎麼樣。這個東西的目的就是將這些個人資訊管理的 資料和上層的應用分開,比如郵件管理,沒有必要每個郵件程式都去搞一套POP3或者IMAP接受,只要從一個地方獲得資料就好。甚至考慮到這個資料來源可能 不在你的電腦上,那麼無論是你在公司的Gnome,抑或是筆記本上的KDE(舉例而已),都可以享受到同樣的資料服務。

同時在Web Application如此氾濫的年代,它同時也可以起到整合各個資料來源的功能,比如日曆,你可以使用遠端檔,也可以使用本地檔,以及其他各個日曆服務。甚至作為微博客的資料端(我看到現在已經支持這個功能了,但還沒有測試過)。

他獲得爭議主要有以下幾大原因,使用Nepomuk,後臺進程,使用Mysql,以及早期bug繁多(這也是沒辦法)
早期來說這個實現還並不成熟(KDE 4.4時期),現在(KDE 4.6)已經變得更加成熟了一些。

為什麼使用MySQL,這點的理由其實和Amarok的開發者很類似(原文翻譯), 對於很多人喜歡的SQLite,他們的理由是無法支持高併發的訪問。為什麼沒有和Amarok一樣使用MySQL的嵌入模式,這是因為它無法支持 InnoDB(MySQL的一個存儲引擎,支援事務)。當然,和Amarok略有不同的一點是他還支援PostgreSQL作為存儲引擎。

為什麼需要Nepomuk?[1][5]

他們需要對虛擬資料夾進行快速的搜索和管理,Kmail自己的實現對於大量的檔來說已經不夠了,而Nepomuk正好滿足了他們的需求。同時,Nepomuk也可以提供有效的中繼資料查詢服務。

關於資源的佔用方面,我想大概這就是一個Trade off的問題,尤其是在硬體條件已經發展的情況下,不過話說回來,我運行很久KDE 4.6之後,同時Kmail也開關過幾次。把所有程式都關閉(firefox之類)只剩桌面之後佔用資源也不算很多。考慮到我的筆記本是4年前的純種聯想 筆記本的話,其實我覺得沒什麼大不了的。

對於希望使用羽量級桌面的人來說,我覺得某種程度上需要做出取捨,自然,有Xfce,LXDE這樣優秀的羽量級桌面供你使用,同樣的如果你選擇了KDE的話,那麼你可能還是期望著更好的桌面體驗,不是嗎?(除非是它佔用了不該佔用的資源,那麼你應該去彙報bug,:) )

對於用戶來說,可以利用Akonadi達成平滑的跨桌面的個人資訊管理體驗。對於開發者來說,則可以利用各種各樣的現有資源實現自己的應用。我個人喜歡KDE的一個原因就是我總是能在他上面體會到各種各樣的新鮮的技術。

從目前Akonadi已經具有的功能和KDE現有的應用來說,我能想到很多有趣的玩法。KDE總體來說給我感覺是非常Web友好的,從Get New Stuff和openDesktop的集成來看,從Plasma對Google Gadget的支援來看,從Akonadi的後端也有很多Web資源(網路下載ical檔,日曆支援blog,微博後端等)來看,我覺得在Web App發展到極致之前(比如Chrome OS真的能以不變應萬變,雖然這在什麼時候能夠實現也未可知),KDE肯定是一個很好的選擇,不過到那時KDE會發展成什麼樣呢(其實我很期待KDE佔領 移動平臺,從我第一次看到手機上跑起來的Plasma就開始期待了) ?同樣也是異常值得期待的。

資料來源:
1 Akonadi, Nepomuk and Strigi explained
2 KDE PIM – Akonadi
3 Akonadi – KDE Userbase
4 Akonadi – KDE Techbase
5 通向KDE4之路(十七):KDE PIM庫和相關技術

http://ikde.org/%E6%8A%80%E6%9C%AF/%E9% ... 89akonadi/
訪客
 

回到 KDE 一般討論

誰在線上

正在瀏覽這個版面的使用者:沒有註冊會員 和 1 位訪客