本日はシナリオから

今回の例で言えば、
●スマフォで【部屋の画像転送】ボタンを押したとして➡
●スマファ➡WebSocket➡HomeServer➡IoTContorollerと制御が渡り➡
●IoTコントローラが画像を受信➡HomeServerに戻す➡WebSocketでサーバに戻す➡
➡さらにWebSocketでスマフォ側に戻す➡表示する
という仕組みですが、画像をどう渡すかという問題です。

どう渡すかってどういう意味？

まずCameraで撮影してそれを取得。この段階ではJPEG
しかし、これをHomeServerに転送する。
ここで汎用性やらいろんなことを考えてbase64する設計にした。
これ以外の方法は、また別途検討するとして、今はbase64で考える。

さて、HomeServerが今度はWebSocketでWeb側に戻す。
このときも、base64のjpegが渡る。
問題はこっから先だ。ブラウザ側としての選択肢はとりあえず２つ。

●画像の参照
●画像そのもののストリーム

画像を参照すると、参照方法はおいといても、一時的にファイルを作成することになる。
これのライフタイムやセキュリティ的にちょっとめんどい。
いや、面倒なことを美しくプログラムで解決するっていうのが信条ではある。
別な言い方をすると、、

テンポラリファイルを作ってなんらか参照させるって、あんまり美しくない

のだ。私の正義としてな(o^^o)
ということで、画像のストリームを作ることを考えると、ひとつの問題がある。

問題って何なのさ(o^^o)

画像のタテヨコは予め知っておいた方があとあと便利

ということだ。
画像のサイズを取るには、jpegのbase64をdecodeしなきゃならない。
いやいや、よく考えよう。
encode、decodeは一度ずつが美しいハズだ。
ってことは、最初にencodeする前にサイズを取っておくべきっていう結論かもしれない。
でもそうすると、

汎用的っていうなら、強制するのは、base64止まりくらいのがいいよね

そう、decodeを何回もするのは美しくないけれども、
IoTコントローラは全般的に性能が低いと考えると、そこでやらせることは最低限にしたい。
まぁもちろん、、今の時代、そんなことを考えなくても良いレベルのボードコンピュータがあるっちゃあるわけだけど。
今回で言えば、

IoTコントローラの最低ラインは、RaspberryPi zero

と考えてるので、うん。どうだろ。
でもよく考えたら、ストリーミングだってやろうと思えばやれる性能があると思うので、
そう考えると、どっちでもよくなる。

こういうときはどうするかというと、

結論

実験してみる

ということですね。
で、とりあえずは、Webサーバ側とHomeServer側の両方で画像サイズをとってみることにします。