情報の世界では、情報を共有する効果的な方法と、それを保存する方法の両方が必要です。 最新の各システムはいくつかの異なるDBMSを使用します。各DBMSには独自の利点があり、特定のニーズを満たすように選択されています。 ただし、形式の多様性により、リソースとの互換性とコラボレーションの問題が生じます。 データの重複とフォーマットの非互換性の問題を解決するために、調査したKDE4の4番目の柱であるAkonadiプロジェクトが開始されました。
Akonadiは、デスクトップコンピューターの個人データおよびメタデータ用の拡張可能なストレージシステムとして作成され、読み取り、書き込み、および作成要求への同時アクセスを提供します。 さらに、Akonadiには、検索やキャッシュなど、データへの迅速なアクセスを可能にするいくつかのコンポーネントと、それらの変更に関する通知が含まれています。
アコナディの仕事の本質は何ですか、なぜそれが必要ですか?
これがすべて必要な理由から始めましょう。 KDE 3では、個人情報管理アプリケーション(Kontactなど)は、データと設定を別々に保存し、同じデータを複製します。 KMailとKResourcesの組み合わせは、その可能性をすべて使い果たしました。共有リソースとそれらへの非同期アクセスの問題を解決する時です:KDE3では、KontactはRAMにアドレス帳のコピーを6つ保持します! さらに、目標はより標準化されたものを作成することでした。このようなオープンなプロジェクトは、他の大規模で重要なプロジェクトの開発のニーズと方向を考慮しないと開発できません。 そのため、プラットフォームと開発ツールに依存せずに、D-Busサポートを使用して、データの保存と交換のための標準形式に基づくクライアントサーバーシステムを作成することが決定されました。 このアイデアの実現はAkonadiでした。
合理的な疑問が生じます-任意のデータ型で動作することを約束する十分なグループウェアソリューションがすでに作成されていませんか? すぐに説明します: Akonadiはグループウェアサーバーではありません! 対照的に、Akonadiは中間リポジトリであり、個人データの抽象化レベルです。 これは、以前にレビューされたフォノンとソリッドに似ています。
この図は、Akonadiアーキテクチャの主な側面を示しています。 すべてが集中型データウェアハウスに基づいており、特定のプラットフォームやプログラミング言語に縛られていないプロトコルを使用してアクセスします。 このプロトコルの上に、リポジトリ内の個人情報にアクセスするために使用される一連のAPIが編成されています。 Akonadiの顧客には2つのタイプがあります。 最初のタイプは、Kontact、Evolution、KOfficeなどのアプリケーションです。 2番目のタイプは、Akonadi中央リポジトリが外部データソースと情報を交換できるようにするリソースです。 このようなソースには、グループウェアサーバー(GroupWiseやOpenExchangeなど)、その他のストレージメカニズム(iCalendar、vCard形式ファイル)、または標準プロトコル(IMAP、POPなど)があります。
これは完全な図ではなく、単純化されたユースケースを示しています。 Akonadiは柔軟なシステムとして設計されており、幅広いアプリケーションとリソースで利用できます。 Akonadiのコンセプトの一部は、新しいAPI、関連するクライアント、およびソースを追加することは非常に簡単であるべきだということです。
このアーキテクチャには、KDE3に比べていくつかの利点があります。
- 個人データは、単一のコピーでメモリに保存されます。
- システムは集中化されているため、一度にすべての変更が発生し、すべてのコンポーネントが最新バージョンのデータを処理できます。
- Akonadiアーキテクチャは、非同期データ交換を整理するように設計されています(データ交換中にアプリケーションが「フリーズ」することはなくなります)。
Akonadiは一般ユーザーに何を提供しますか?
ユーザーにとって、利点はそれほど明白ではありませんが、それでもかなり重要です。 前述のように、すべてのアプリケーションは同じストレージを使用するため、メモリ内のデータを複製する必要はありません。 したがって、少ないリソースを集中的に。 さらに、IMAPの拡張バージョンを使用してストレージにアクセスするため、データ抽出の速度が向上します。 同じIMAPプロトコルは、個々のアプリケーションごとに実装および拡張できる基本的な検索機能を提供します。
誰もがおそらく、カレンダーのようなプラズマアプレットを知っている、メモを残すなど。 -すべて同じAkonadi共有を使用します。 また、以前にアプリケーション間でデータ同期の問題を確認できた場合(たとえば、Kopeteが連絡先情報を変更し、Konversationがその情報を参照していた場合)、Akonadiサーバーが同期の問題を処理し、データはすべての場所で自動的に更新されます(誕生日など)プラスモイドカレンダー)。 さらに、リモートサーバーとのデータの同期は、ユーザーに対して完全に透過的になります。
さらに、個人データを他のKDEアプリケーションにさらに便利に統合することができます。 たとえば、ユーザー名に加えて、ファイルのプロパティに彼の写真を表示できます。 Akonadiサーバーとデータソース(たとえば、同じグループウェアサーバー)間のデータ交換のコンポーネントは、エラーの場合にシステム全体の緊急シャットダウンを回避するのに役立つ個別のプロセスに分割されます。 コンポーネントの失敗したプロセスを再起動するだけで、データが再度ダウンロードされます。
Akonadiはプログラマに何を提供しますか?
Akonadiは、通常PIMの開発で最も難しい部分であるデータの受信と保存を処理するため、PIMアプリケーションの開発が容易になりました。 たとえば、Akonadiを使用したMailodyのフレームワークは10分で作成されました。
Akonadiアーキテクチャの主な機能:
*個人データの一般的なキャッシュ
- リソースに依存しない設計
- 拡張性
- オフラインでの基本アクセス、変更の記録と再生
- 基本的な競合検出および解決システム
- リソースはプロファイルごとにグループ化されます
- データ要素は、多くの独立して取得された部分で構成されています。
*同時アクセスにより、インターフェイスに関係なくバックグラウンドプロセスが可能
- メール、カレンダー、アドレス帳とリモートサーバーの同期
- モバイル同期
- セマンティック環境インフラストラクチャが個人情報にアクセスできるようにします
- アーカイブ
- 索引付け
- アウトプロセス検索
*マルチプロセス設計
- クラッシュ絶縁
- 大きな要素はシステム全体をブロックしません
- IPCリンクにより、独自のコンポーネントが可能
- シンクライアントインストールは、コンポーネントを共有してスケーラビリティを高めることができます
リソースタイプ非依存とはどういう意味ですか? グループウェア、IMAP、MS Exchange、vCard、およびその他すべては、さまざまなエンジンを介してサポートされる個別のリソースです。 PhononやSolidのように、異なるプラットフォームのエンジンは、さまざまなタイプのデータソースを操作するための理論的に無限の可能性を提供します。 開発者には作業用の単一のAPIが提供されるため、個人情報を操作するためのアプリケーションを作成することは、桁違いに簡単になります。
Akonadiとそのコンポーネントの全体的な設計は、 APIドキュメントで説明されています 。 詳細については、Techbaseプロジェクトページを参照してください 。
情報は、 Akonadiの公式Webサイト 、 ロシア語版ウィキペディアのAkonadiに関する記事、およびAbunadiの主要な開発者の1人であるTobias Koenigの kubuntu-de.orgに対するインタビューから取得されました。 また、Akonadiの公式Webサイトに投稿されたプレゼンテーションスライドが使用されました。
これは、私の記事とWeLinux.ruのクロスポストです。