前の一編で窓が二つあると書いた。人が機械を直接扱う窓はMCPが狙った席ではなく、足りないのは画面だと書いた。
この一編は、その画面をどこから持ってくるかだ。
前提をひとつ変える
普通はホストが画面を知っている。どの装置がどの値を出すか、その値をどのウィジェットで描くか、どのボタンがどの命令を送るかをアプリが知っている。だから装置がひとつ増えるとアプリを直す。
変える前提はこれだ。画面をホストではなく装置が定義する。
装置はすでにMCPサーバーとして自分の機能を道具として出している。ここにひとつ足す — 自分の画面を宣言的に記述する。 クライアントはその記述を受けてネイティブに描く。ブラウザも組み込みウェブエンジンも要らない。
するとクライアントは何を描くかを あらかじめ知る必要がない。 初めて見る装置も、つないだ瞬間に扱える。
机の上の二枚
これは言葉にするともっともらしく聞こえる。だから実物で確認した。
ボード二枚だ。STM32H723 はUSBシリアルでつながり、ESP32 はWi-Fiでつながる。発見のしかたも違う — 一方はポートを開けて探し、他方はネットワークで探す。電気的にも伝送路的にも互いに他人である。
各ボードにブリッジが付いて自分の機能を道具として出し、自分の画面をリソースとして出す。そしてクライアントは 両方に対して同一だ。 ボードごとの分岐がない。
画面が出る。ボタンを押すと 机の上のLEDが実際に点く。
このサンプルには規則がひとつ掛かっている — ボードがなければ通さない。 シミュレーションで代えず、どのポートを探したかを明かして失敗で終わる。ハードウェアなしで「検証」されるハードウェアの話は、検証されたことにならないからだ。