go-ldap の syncrepl 対応
2時に寝て2回ぐらい起きて6時半に起きた。お休みとったからいろいろ余裕がないけれど、体力だけはある。
syncrepl 機能の実装⌗
go-ldap の非同期検索 の続き。persistent search という用語 も理解して、満を持して openldap の syncrepl 対応に臨んでいた。syncrepl を用いた persistent search というのは、簡単に言えばメッセージキューで言うところの pubsub のコンシューマーに相当する。その通信のテストやデバッグをしているときに非同期検索のバグもみつけた。余計なことをして返って複雑なバグを混入したなと反省しながら修正の pr を送った。
go-ldap の ldap 通信の処理や設計を理解するのに2日、rfc-4533 を読みながら Control に関するプロトコル実装に1日、テストやデバッグ、その他の調査や設計に2日ぐらい、次の pr を作るのに1週間 (平日5日) ほどは工数を割いた。
ローカル環境で単体レベルの動作は問題ないと思う。あとは私が知らない ldap プロトコルの振る舞いや単体レベルで検証できていない通信、実際の運用レベルの syncrepl の状態やエラーなどに耐えられるかどうかといったところだと思う。おそらく rfc を読みながらプロトコルの一部を私が実装したのは初めてかもしれない。もうサーバーサイドやバックエンドの領域で (スキルの多寡はあれども) 私が作れないものはそうないだろうという自信をもっている。実際に rfc で提案されたプロトコルを実装して、テストして、ちゃんと動いて、そういう日々がすごく楽しくて嬉しかった。根拠のなかった自信を確認できた。またレビューに時間かかるかな?マージのためのやり取りや修正に2週間から1ヶ月ぐらいを見込む。