Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Antitrust Statement

All Linux Foundation (LF) activities are subject to compliance with the LF’s Antitrust Policy. Each individual participant and attendee at this meeting is responsible for complying with the LF Antitrust Policy. The LF Antitrust Policy is available at the URL link below or, if applicable, may be immediately emailed to anyone attending this meeting.

http://www.linuxfoundation.org/antitrust-policy

Participants of this meeting must NOT discuss:

  • The business strategy of any Member
  • Any attempts to restrict or hinder the growth or use of another industry standardization initiative
  • Actual, projected or future prices, or sales terms of their products
  • Marketing strategy, production capacity or release dates of their products
  • Allocation of customers or customer categories for their products

Attendee



場所

  • Web meeting

日時

  • 6月16日(火)　１５：００－１６：００

議題

InputManager テックレビュー

議事


資料

  • 200616 AGL_Input_Manager.pptx


議事録メモ

  • 以下、PPT資料説明に対する協議内容
    • Containerは常に動作している前提で良いか？
      • アプリContainerが落ちることを前提とすべき。Restartは必要。
      • Server/Cilentモデルで、Restartできるようにしておいた方が良い。
    • 大前提として、コンテナ間での通信は作らない方が良い。
      • Container間の通信が発生するDasiyChainは適さない。
      • Server/Cilentモデルで、ClientはMultiClient方式にした方が良い。
      • Host側InputManagerをServerとし、アプリContainerはMultiClientとする。
    • この場合の課題はレイテンシーとなる。
      • 構造は複雑となるが、HostとContainerでInputManagerをネストさせることでレイテンシーを小さくする。
      • Host側のInputManagerとClusterContainer内部のInputManager間で、イベント消費する・しない、を判断する。
    • Container内部に配置するInputManagerのLifeCycleが問題になる。
      • アプリContainerが死んだときに、どのようにしてHost側のInputManagerに知らせるか？
        • 例えば、ServerとClientでセッションが切れたときに、Host側はClientのInputManagerが死んだと判断する。
      • アプリContainerが死んでいるときor起動中の時に、Host側のKeyイベントはどうする？　捨てる？　キューイングする？
        • Keyイベントは捨てる、で良い。
    • Clusterがダイレクトで受けなきゃいけないKeyイベントは何か？
      • ADASやTripComputerの表示切替など。
      • ＋/－キーなどは、Clusterは要らない。
      • そもそもで、ClusterとIVIで共有するイベントはなさそう。
    • Keyイベントの動的な割り当て・変更は必要か？
      • ClusterとIVIのKeyイベントの割り当てに関しては静的に決定できるため、動的な変更は考えないこととする。
      • Hostとしては、静的なConfigurationで済ませる。　動的な変更は考えない。
      • HostとClusterのInputManagerはSimpleな形とする。
      • IVIのInputManagerは、動的に通知先が変わる・変更する可能性が出てくるので、Hostとは明確に分離する。
    • 実装モデルはどうするか？
      • 通信手段
        • Container間通信としては、UNIXドメインソケットが一般的。
        • それ以外の手段としてはVX-CANがあるが、一般的ではない。
      • API
        • 必要なAPIは、Register、Unregister、Notify、Response、の４つか。
        • Unregisterは必須ではない。実際に使用するかどうかはわからないが、動的に登録解除する可能性もゼロではないため準備する。
        • Responseは、アプリContainer側でイベントが消費したことをResponseするために使用。
      • データフォーマット
        • 規定する必要あり。（次回宿題）
  • 今後
    • 本日協議内容に基づき、InputManager検討資料の更新　（山岸さん）
    • アーキテクチャOverviewも本日の協議結果に基づき更新可能なので、反映する　（丸山）


次回

XX/XXの週

座長：XXX


  • No labels