Page Comparison

...

• 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日(火)　１５：００－１６：００

...

• 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が死んだときに、どのようにしてHost側のInputManagerに知らせるか？
    • 例えば、ServerとClientでセッションが切れたときに、Host側はClientのInputManagerが死んだと判断する。
    • アプリContainerが死んでいるときor起動中の時に、Host側のKeyイベントはどうする？　捨てる？　キューイングする？
    • Keyイベントは捨てる、で良い。

    ...

    • ADASやTripComputerの表示切替など。
    • ＋/－キーなどは、Clusterは要らない。
    • そもそもで、ClusterとIVIで共有するイベントはなさそう。

    ...

    • ClusterとIVIのKeyイベントの割り当てに関しては静的に決定できるため、動的な変更は考えないこととする。
    • Hostとしては、静的なConfigurationで済ませる。　動的な変更は考えない。
    • HostとClusterのInputManagerはSimpleな形とする。
    • IVIのInputManagerは、動的に通知先が変わる・変更する可能性が出てくるので、Hostとは明確に分離する。

    ...

    • Container間通信としては、UNIXドメインソケットが一般的。
    • それ以外の手段としてはVX-CANがあるが、一般的ではない。

    ...

    • • 構造は複雑となるが、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