| 日時: | 2017-09-11 |
|---|---|
| 作: | @voluntas |
| バージョン: | 0.0.0 |
| url: | https://voluntas.github.io/ |
Contents
この考えはあくまで自社製品の売上を伸ばすための施策の一つとして考えている。 結果的に WebRTC という技術に対して貢献ができたらよい。
WebRTC API を利用したサンプルは沢山あるが、古かったり、ライブラリに依存していたりと様々だ。 WebRTC API はブラウザごとに使用が異なる上に、かなり短い間隔でアップデートされていく。
特に JavaScript API は簡単に試せる点で、様々なサンプルが転がっている。また iOS/Android に関しては逆に資料がほとんどない。 さらに言えば組み込みむけの WebRTC Native API について書かれている資料はまったくない。
継続的に更新され、維持されていく WebRTC API 関連の資料が必要だと考えている。
ここを見れば問題ない が欲しい。
自社の製品で WebRTC を利用した製品を扱っていることもあり、これらの情報が散見されるのは喜ばしいことではない。
また、技術をはやらせる方法としては、更新される信頼できる技術資料があるのはとても重要だと考えている。
大事なのは継続。それ以外は特にない。品質は最初は悪くても良い、継続によって上げていく。
自分が知る限りこの 3 冊がまともな WebRTC 関連の技術書という認識。とくに わか(った気にな)るWebRTC は素晴らしい
ただ、これらも最新版やブラウザごとの差、実際にアプリを作る際のサンプルとしては厳しい。また書籍の更新は遅い。 必要なときに追従していることはまれ。
- 仕事で WebRTC を 触っている間 だけ必要
- 仕事でかかわらなくなった場合は必要なくなる
- 資料は仕事で関わり続ける人がべき
- getUserMedia のブラウザごとの仕様
- iOS 上での Safari での動作や、 Android 上での Chrome の動作
- P2P と SFU/MCU でクライアントの動作が異なるのは明確にしたい
- シグナリングが自由すぎることもあり、サンプル用のシグナリングルールみたいなのを決めておきたい
- ライブラリごとに依存しすぎ
- Signaling を含めたライブラリに依存している事が多い
- WebRTC API のプロトコルレベルとの密接した API の解説がほとんどない
- ブラウザごとに対応している API が異なる
- Adapter.js を使った例があまりない
- Babel を使った例を用意したい
- React のサンプルも提供したい
- React-Native を利用したサンプルなどもない
- Cordova なども需要はありそうだが、この辺範囲は決める
- 理想としては Native API の解説なども書きたい
- 組み込み WebRTC を流行らせたい
どのブラウザでいつぐらいに、何が実装されるか。というのはかなり聞かれる事が多い。
といってもブラウザを作ってる企業側の都合が全てなので、あくまで参考にしかならない。
それでも欲しい情報らしいので、ここはきちっと書いておきたい。
Safari や Firefox や Chrome のリリース情報は、所定の場所にある。これらをすぐに見られるようにしておきたい。
Edge はそもそも仕様がよくわからないので、なんとかしてほしい。
WebRTC を理解するのに一番いいのは手動シグナリングなので、もう少し普及させていきたい。
ブラウザごとの追従を整理していきたい。
- 最新版のみ
- Chrome, Firefox, Edge, Safari で、さらに Stable 限定
- どの API が使えて、使えないのかを明確にする
- 最新のブラウザにのみ対応させる
- Canary などの最新ナイトリービルドは対応しない
- メンテコストが膨らむ
- iOS/Android は最新は難しいので一つ前くらいから最新で維持する
- ~ でも動いたなどの報告はボランティアに期待する
- Native API は固定した環境でのみ確認を行う
- ~ でも動いたなどの報告はボランティアに期待する
- ボランティアによるメンテナンスは不可能
- 善意は期待しない
- https://www.bountysource.com にお金を払って書いてもらう
- 図などの管理をどうするか
- 画像をコミットはしたくないので、考える必要がある
- オープンに公開するか
- GiHub にて公開したい
- 有償での提供をするか
- 無償で提供したい
- ドキュメントの修正は受け付けるか
- 受け付けたいが品質チェックのコストをどうするか考える
- タイポ関連は大歓迎
- 新規については、要相談
- 基本は 間違い修正 を期待する方針が良い
王道である WebSocket と JSON を利用した 汎用的なシグナリングプロトコル を用意するのが良いと考えている。
- JSON は Type と SDP そのまま
- WebSocket もシンプルに利用する
- P2P 限定で考える
- MCU/SFU については、別途解説をする程度にしておく
シグナリングの規格を統一しなかったのはとても良いことだとは思うが、それがハードルを上げているのも事実だ。 シグナリングが何をするためのもので、どんな動きをしなければいけないのかをわかりやすく維持する必要がある。
coturn サーバの解説があるのが一番よいが、そもそも TURN サーバがなぜ必要なのか、 WebRTC API 的にどう影響してくるのかはまとめておきたい。
ただ、このあたりは WebRTC API 使ってプログラミングをする点では関係ないので、今回の資料に入れ込みたいとは思っていない。
iceServers あたりの説明をすれば十分だと考えている。ただ username と credential のあ使い方みたいなサンプルは用意したい。
getStats API から始まり、 chrome://webrtc-internals や about:webrtc など。
このあたりの使い方や、意味などをきっちり説明しておくことで、開発者が学ぶことは多いと思う。
WebRTC は音声や映像、さらに DataChannel では非同期通信を扱うことからテストがとてもむずかしい。
テストをどうやっておこなうのか、などの例があるのはとても良い思う。