案: Piping Serverの送信者に送信結果がプログラム側から理解しやすいようにする案
例
正常に送信が完了した時。
code:console
INFO Waiting for 1 receiver(s)... INFO A receiver was connected. INFO Start sending to 1 receiver(s)! {"ok": true}
受信者が途中で接続を切った時。
code:console
INFO Waiting for 1 receiver(s)... INFO A receiver was connected. INFO Start sending to 1 receiver(s)! INFO All receiver(s) was/were closed halfway. {ok: false, "error": {"code": "closed_halway"}}
最後の行にあるJSONを解釈すれば接続結果がプログラム側で処理しやすくなる。
必要になる背景
現在だと[INFO] ...から始まる人向けのログの文字列に特定の文字列が含まれていることを使うような方法しかない。ただしこれは言い回しを変える可能性がありプログラムで処理すべきではない（現在作ったどのアプリケーションでもこのログで条件分岐することはしていない）。
送信者のHTTPのエラーコードは接続が確立した場合は常に200が変える。HTTPにフッタはないはずので送信結果を知りたければ上記の例のような方法になると思う。 設計に関して
パースするときは行の最後をJSONとしてパースする。
最後の行のJSONは改行されることはなく1行にする。
JSONにするのは拡張のしやすさを重視したいから。 ok: booleanなしで{error: ...}だけで良いのではというはある。
TypeScriptなどでokなしの方が処理しやすい気がするというよりokを使わなくなりそう。errorがundefinedかどうかでokを判断する実装になると思う。 okをつけたくなる理由は一般ユーザー目線に立っているから。だた正常終了のときに{ }だとなんとなく不安になるし何なのか気になる。また{error: null}などで正常終了させると一般ユーザーからすると"error"の文字があるためエラーしたのかと勘違いしそう。
okがある場合は型で{ok: true} | {ok: false, error: Error}のように定義できるためok: falseの時だけerror: ...があるのはTypeScriptのような型システムだと実現できるはず。 ただ冗長なデータが紛れ込むのは経験的に色々と保守性に影響が出るので避けたい気持ちもある。
エラーコード
仕様をみなくても意味が把握できるメリットがある。
HTTPのように数値を使うと仕様みたいな表を常に見る必要があるため文字列にしている。 文字列リテラル型がある言語だと安全に処理できる。
毎行JSONにするに関して。
接続状況のリアルタイムな確認ができできればこちらの方が嬉しい。
条件分岐は減らしたいのでJSONにするかどうかのフラグはなるべく無くしたい。
[INFO] ... は人向けで毎行JSONはプログラム向けでこの二者を両立する方法を再考したい。
ログは人向けかプログラム向けか
あの[INFO] ...のログを人は基本的に以下の人に限られると思う。
curlユーザーがか