今後の活動-デバイス間で移植可能なセッション

この投稿は、 今日書かれたこの記事の翻訳です 。



この投稿で最初に気に入ったのは、著者が共通のデータウェアハウスのアイデアを思いつき、Mac / iOSの最近の変更が明らかになったクロスデバイストレンドに触れたことです。



だから、ハニ・アーミテージは書いています。



私はこの投稿を何ヶ月も書き続けようとしましたが、通常は完全な混乱か、その他の誤解で終わりました。 それで、得点するために、私は書き始めます、そして、我々は何が起こるかを見るでしょう。



私が話したいのは、セッション、XSMP、およびウェイランドでした。







アクティビティ（KDEアクティビティ）は、XSMP、Xセッション管理プロトコル、X線セッション管理プロトコルを使用します。 ウィンドウのグループを保存および復元するために使用します。 以前は、ログイン時にセッションを再開するためにのみ使用されていました。 実際、このプロトコルは通常考えられているよりもはるかに優れており、数十年にわたって優れた機能を発揮していますが、時代は変化しています。 前進し、いくつかのデバイスの一般的なセッションのようなクールなことをしたい場合、何か新しいものが必要です。 アクティビティでも、XSMPの制限を拡大しているため、不要な隠された松葉杖がたくさんあります。



ですから、重要なことは、古いが信頼できるテクノロジーを新しいものに置き換えたい場合、この新しいものをより良くするだけでなく、 はるかに良くしたいということです。 本当に進む価値のあるもの。 XSMPの自動保存の欠如などの小さな問題は簡単に解決できます。 しかし、XSMPがプロセスベースであるという大きな問題もあります。 セッションキーは個々のプロセスにマップされ、回復する必要がある場合、セッションキーが引数として渡される特定のバイナリを呼び出すことでこれが発生します。 これが悪の根源です。 そもそも、プロセスに多くのウィンドウ（コンソールなど）がある場合、これらのウィンドウを複数のセッションに正しく分散させることはできません。したがって、アクティビティはあらゆる種類の処理を行ってユーザーから隠す必要があります。 第二に、さらに大きな問題は、そのような方法がとてつもなく耐えられず、不透明であるということです。 プログラムのバイナリがどこかに移動した場合はどうなりますか？ ユーザーが古いアプリケーションを置き換えるために代替アプリケーションを使用し始めたらどうなりますか？ そして、もちろん、デスクトップコンピューターと同じプログラムがユーザーの携帯電話にインストールされることはありません！ meegoに電話があり、すべてのモバイルデバイスと非モバイルデバイスでCalligraを使用している場合でも、電話のバイナリは異なる方法で呼び出されます。 ：P



そして、私たちは何をしますか？ リソースを使用しましょう！ :)データを標準形式で標準の場所に保存します。 そのため、セッションマネージャーは、「このセッションでは/ usr / bin / firefox、/ usr / bin / konsoleおよび/ usr / bin / okular」ではなく、「このセッションではWebページX、Y、およびZ XとYが1つのウィンドウにグループ化されて、Firefoxを使用してこのデバイスで最後に開かれたとき。 前回コンソールを使用した2つの端末。 foo.pdf、3ページ目で開き、okularを使用してこのデバイスで前回開かれました。 その後、okularが利用できない場合、システムからpdfを開くプログラムを要求できます。したがって、ユーザーが電話にセッションを送信するときに、電話が別のpdfリーダーを使用していても、電話ブラウザーがタブをサポートしていなくてもかまいません。 さらに、3ページではなく20ページが開かれた場合、電話は「おお、やや多い。 最初の3つだけを開き、他のすべてのリンクを特別な場所に表示します。」 または、たとえば、「なぜ「ごみ」と呼ばれるアクティビティを作成したのか」と考えることができます。 一体何なの？」と、このセッションをダウンロードしなくても答えを得ることができます。



コインの反対側は、ささいなことが決定するということです。 最近、OSXがセッションに対する真剣なサポートを追加したと聞きました。 彼らはiPhoneの例から学び、その知識をデスクトップに適用しました。 現在、アプリケーションが突然落ちても絶対に重要ではないシステムがあります-オペレーティングシステムはいつでもそれを殺すことができます-セッションサポートは非​​常に優れているので、アプリケーションは以前と同じ状態に回復します。 Linuxでも同様の品質のセッションのサポートを見ることができれば非常にうれしいです。 KDEアプリケーションでは、XSMPのサポートはすでにかなり優れていますが、さらに優れている可能性があります（その前には、自動保存プロトコルにはまだまだ先があります）。



現在、XSMPの置き換えはまったく新しいアイデアではありません。 XSMPの小人はかなり長い間それを好まなかったが、彼らのいずれも代替手段を作成するための措置を講じたとは思わない（そしてXSMPはとにかくその目的に適している）。 数か月前にネポムクのチームのメンバーと、デバイス間でセッションが転送されることについて話し合ったとき、彼らはすでにそれについて考えていたことが判明しましたが、そのようなプロジェクトの政治的部分は複雑すぎると判断しました。 彼らはまだ正しいかもしれません-見てみましょう。 しかし、試してみる価値があります。 :)



それでは、難しさは何ですか？ XSMP for Activitiesの開発で私が立ち往生している問題は次のとおりです。新しいプロトコルを持つことは、そのプロトコルをサポートするようにアプリケーションを説得する必要があることを意味します。 XSMPのサポートは、問題がないわけではありませんが、最近普及しており、ほとんど抵抗がありません。 新しいプロトコル...まあ、彼らはKDEでそれを使用することはかなり確信していますが、いつかgtk、純粋なqt、meego、さらには曲がった独自の工芸品のアプリケーションの一部になりたいです。 そして今、これは本当のテストです！ :)



では、このテストをどのように乗り切るのでしょうか？ そもそも、どのパンを追加するのかをみんなに説明します-私はそれをかなり上で説明したことを望みます。 次に、適切に設計された使いやすいAPIをアプリケーション開発者に提供します。これにより、実際に何かをする開発者からの反応が生じるはずです。 IRCの人が最近XSMPで宣誓しているのを見ました:)第三に、結果が努力に値することを知るのに十分な同情があるとすぐに、実際に機能する信頼性の高い実装を示します（重大なバグなし）。 見ることは信じることですよね？ まだ存在しないシステム用のコードの作成に貴重な時間を費やすことを望む人はいないので、最小限の機能セットを作成し、いくつかのアプリケーションを作成したら、すぐにすべてを表示します。 4番目-秘密の武器:) Waylandは人気を集めており、アプリケーションがそれに切り替え始めると、彼らも私たちのプロトコルに切り替えることができますよね？ Waylandには独自のセッションのプロトコルはありません;私たちのプロトコルは1つになるかもしれません。



誰が私と一緒にいますか？ デスクトップサミットまであと数日です。突然、私が主催者になりました（yahhoo！）そして、上記のトピックについて話し合いたいと思います。 結局のところ、これは、デバイス、デスクトップ、およびあなたが望むものの間でポータブルであることを目指している何かのための素晴らしい場所です。



TL; DR：リソースベースのセッションプロトコルにより、非常にクールなことができるため、XSMPを置き換えることは価値があります。



今、私は技術的な詳細を掘り下げたい（このいまいましい悪い作家症候群のためではないにせよ、このトピックに関する全著作を書くのに十分な資料を持っている...）



...



そして、私たちが何について話しているのか、技術的な詳細。 本当に何を実装する必要がありますか？ どのようなAPIが必要ですか？

3つの相互接続された部分があります。 1つは共有ストレージです。 XSMPはセッションデータの保存方法について何も言わないため、最初に来ます。 アプリケーションは、このデータを使用してすぐに起動することも、XSMPサーバーによって引き続き起動することもできます（これは、移行フェーズでは適切なソリューションになる可能性があります。長時間かかります。それほど大きな変更はありません。）



わかりました...私はストレージ施設をあまり勉強しませんでした。 nepomuk / tracker / zeitgeist、またはkconfigなどのテキストファイル、またはレジストリ（eek）に保存することができます。システムがタスクにうまく対応し、デバイス上のすべてのアプリケーションがそれだけを使用することが非常に重要です。 さまざまなバックエンドがさまざまなデバイスに適していることが判明する可能性があります-私はこれをまだ理解していないので、さまざまなアプローチのプラス面とマイナス面に関する情報を聞きたいです。 アプリケーションは定期的に特定のデータを更新します-通常のページ、フィルム内の位置など-したがって、効率についても聞きたいです。



少なくとも、データ形式の大まかなスケッチを作成しました。 リソースの主要部分は、いくつかのURI（通常はローカルまたはhttp）とドキュメント内の位置です。 URIがキーになり、位置がフィールドの1つになります...他のフィールドは、このリソースが配置されているウィンドウになります（最終的には、ウィンドウはウィンドウマネージャーの論理ユニットのままであり、その位置とサイズは重要なセッションデータです）。アプリケーション、プログラム用の独自のデータフィールド（できれば小さいほど良い）、およびおそらく他のデバイスからのデータ（デバイスが単独で対処できないソリューションを支援するため、またはセッションがこれらのデバイスに転送される場合データは彼になります ）を意味します。 ウィンドウのセッションデータは、おそらくウィンドウマネージャー自体によって記録されます。実際、きれいなボードとより多くのプログラマーが適切なデータ構造を考え出す必要があるため、ベルリンでこれを行うつもりです。 そして、これらの決定でさえ実装中に変更されると確信しています:)最初は、機能する少なくともリソースベースの構造を構築することが重要です。



2番目の部分はセッションマネージャーです。 これは、セッションが開かれたときにアプリケーションをロードし、必要に応じて閉じるように指示するプログラムであり、ほとんどの場合はデーモンですが、必要ではありません。 インタラクティブなプロセス（「このドキュメントを保存しますか？」）がある場合、これも処理する必要があります。 これは、ksm-serverが現在XSMPに対して行っていることです。 実際、構成ファイルの読み取りと書き込みにかかる時間の大部分はそれほどかかりませんが、ユーザーとの通信を要求する（セッションを一時停止する）アプリケーションや完全にキャンセルするアプリケーションの機能により、すべてが複雑になります。



3番目の部分は、ほとんどの開発者に表示される透過的なAPIです。 APIを良くしたいです。 また、下位互換性と上位互換性が必要です。 実装のバグや設計エラーを修正することを除いて、XSMPは変更されていませんが、新しいプロトコルは変更されます。 ほとんどのアプリケーションには、動的にリンクされた共有ライブラリがありますが、静的にリンクされることを心配する必要がありますか？ 幸いなことに、このようなケースをかなりうまく処理する設計を思いつきました。 私はdbusを思い出します。 彼は、アプリケーションが常に同じ言語で通信できるバス形式について説明していますが、欠点があります-彼らはこの形式を改善することはできません。 ：/



dbusといえば、それは私にとって興味のあることの1つですか。セッションマネージャとアプリケーションはどのように相互に通信する必要がありますか。 効率性の理由から、リポジトリはできる限り直接アクセスできるように作成する必要があると思います（同時記録の競合は、たとえあったとしてもごくま​​れにあり、書き込みと読み取りの同時競合でも同じことを期待しています）。 ファイルシステムのバッファが小さすぎると、パフォーマンスが急激に低下することが予想されます。 最悪の場合、何千ものアプリケーションが同期せずに10秒ごとに状態を更新し始めることを想像してください。 1秒間に複数の書き込み操作が発生することがあります。 幸いなことに、このような定期的な更新を行うアプリケーションは1つまたは2つしかありません（映画を1つしか見ることができず、1つのソースからのみバックグラウンドミュージックを聴くこともできます）が、それでも後で考慮する必要があります。



ちょっと迷いました。 セッションマネージャーとの会話に戻ります。 サブセッション（つまり、アクティビティ）をサポートするためにksmserverとkwinを更新したときに、dbusでタイムアウトが発生して沼地に陥りました。 おそらく、私がこの方法で行ったのは私だけではありませんでしたが、他に選択肢はありません。 XSMPはICEと呼ばれるある種の古代のプロトコルを使用します。これはX11と密接に結びついているようです。 この名前のプロトコルは多数あるため、グーグル検索は非常に不快です。 いずれにせよ、Waylandで簡単に行えるように、X11のタイを破りたいと思っています-彼らはそこで何を使って通信しますか？



さらに議論を続けます（定期的に休憩をとるという事実にもかかわらず、私の手はすでに執筆にうんざりしています）、APIは提供する機会によって正確に設定されます。 最初のバージョンから、最も重要なものを除いて、すべての可能性を捨てる必要があると思います。 ユーザーとのチャットやセッション終了のキャンセルなど。 私は完全にキャンセルする傾向があります。 現在は1990年ではなく2011年です。 アプリケーションが終了するとき、アプリケーションは正しく動作するはずです。 ケイトでさえ、クラッシュから回復するためのスワップファイルを持っています。 セッションを再開するために使用できます。 唯一のマイナスは、それらがそれほど移植性がないということです...しかし、私はこの問題を延期できると思います;）くそー、私は同時に1つのウィンドウをNセッションに追加する機能さえ延期しなければなりません。 事態が非常に複雑になるため、これがアクティビティにとって本当に価値のある機能であるかどうかはわかりませんが、同時にこの機会は、追加のセッションを作成することで実装されます。



それでは、本当にどんな機会が必要なのでしょうか？



-アプリケーションまたはウィンドウマネージャーは、ウィンドウのサイズと位置を記録する必要があります。 最終的にアプリケーションがこれを行う場合、ライブラリの助けを借りて、アプリケーション開発者が心配するべきことではなく、絶対に自動的に行われるはずです。

-アプリケーションは、特定のウィンドウにリソースを表示するという事実を記録する必要があります

-また、表示を停止したことも記録する必要があります:)

-ウィンドウまたはリソースは、表示時に特定のセッションに関連付ける必要があります

-アプリケーションはいつ閉じるべきかを言う必要があります

-アプリケーションは、セッションデータから自身を回復できる必要があります。

-アプリケーションには、セッションに独自の非標準データを保存する方法が必要です



これは、XSMPの力をコピーするための基礎にすぎません。 本当にクールなことを行うには、これも行う必要があります。

-これらのウィンドウが複数のセッション間で分散されている場合、閉じるウィンドウをアプリケーションに正確に伝えます

-セッション全体を再開するか、その一部のみを再開するかをアプリケーションに伝えます

-アプリケーションが共有ポータブルセッションデータ（ドキュメント内の位置など）を標準の場所に保存できるようにし、すべてのアプリケーションがこのデータを使用できるようにします



私はいくつかのことを逃したと確信していますが、あなたはすでにアイデアを理解しました:)



実際、4番目の部分があります：デバイス間の同期。 2つのデバイスはどのようにセッションデータを交換しますか？ リソースと関連データのリストを送信するのはいくぶん簡単に聞こえますが、まだ対処する必要がある多くの詳細があります-どのリソースを他のデバイスにコピーする必要があるか、URI（file /home/chani/Documents/foo.pdfへの変更に対処する方法）固定コンピューターはまったく別の場所の電話に接続されます）同期を試みて競合を解決する方法... :)私についてそれ以上のことを理解している人がいると確信しています。 そして、ボーナスとして、結果の同期コードは、ディストリビューション間、さらにはデータを保存するためのほとんどの異なるバックエンド間での転送の準備ができている必要があります。



これをすべて実現するには時間がかかり、適応にはさらに時間がかかります。 これは長年にわたるプロジェクトです。 しかし、人々が本当に何かを望んでいるなら、これはすべて実現可能です。