The Web That Wasn't - WikiBana #10 LT
•
1 gostou•850 visualizações
Presentation of "the Web" that could have existed, but never happened - which is fortunate for all of us. Why the Web today is in today's shape, and what's (probably) waiting in the future. Presentation itself was interrupted due to PC battery issue, but uploading it nevertheless.
Recomendados
Mais conteúdo relacionado
Mais de Taisuke Yamada
Mais de Taisuke Yamada (18)
Último
Último (10)
The Web That Wasn't - WikiBana #10 LT
- 1. 存在しなかったウェブ なんでこうなった？ －ウェブプロトコルのムダ知識－ @tyamadajp
- 2. 今日のメインテーマ： 「科学コミュニケーション」 … となれば↓この人↓は外せない…よね？
- 3. 元ネタ：「存在しなかった惑星」のあらすじ 万有引力の発見を受け、海王星、冥王星も発見。そして… 私は予言する！ 水星の内側に、新惑星ヴァルカンがあると！ しかし、見つからない。その正体は… ルヴェリエ＝キバヤーシ E=mc^2 ！よってヴァルカンは存在しない！ 物理学はワシが育てた。 賢者 A.E. 太陽の放射エネルギー自体が「惑星 V 」だった
- 5. ウェブプロトコルを巡る「世界観の衝突と転換」 この辺でウェブの「スケール性」の 論考とか、「情報空間」 vs 「分散 オブジェクト」論争とか盛り上がる 1991 2000 2010 HTTP/1.1 (1999) SOAP (2000) REST (2001) 実は 1990 年代後半から「手を出しては世界観が 衝突して七転八倒」な時代があった。 今日はその時代の七転八倒具合をご紹介します。 もはや完全なムダ知識へ GO →
- 6. 昔々、とある IETF の IPP WG “_Dont' Go Postal_” “The Use of Post: A Response”
- 7. 衝突＃１：「 __Don't Go Postal__ 」論争 フフフ… HTTP を POST で乗っ取って ネットワークプリントしちゃうもんね～ あんなことや、こんなこともしちゃうもんね～ IPP 策定中さん アドミン代表（ MS ） 「なんでもかんでも POST るな！途中の FW ちゃんとか負担がきついんだぞ！ プリント一発、情報流出とか管理者を 泣かせるような真似するなぁぁぁ」
- 8. 「 __Don't Go Postal__ 」論争の見所：…文体？ ＜挑戦側 I-D ＞ 「『メールで流出させることもできるよ』って 言うだろうけど、別の（流出）方法があるからと いって予防しない理由にはならないよね」 「『みんながやってるし』：こういう傾向こそ 改めるべきで、これは理由にならないね」 ＜防衛側 I-D ＞ 「へぇー、『 PUSH/PRINT 』命令を作れというのに、 『 (DB)QUERY 』とか『 BUY 』とかは作らないんだ」 「大体 POST 本文じゃなく命令やヘッダで明示すれば 安心とは言えないですね。嘘ついても判る訳ない」 コワイヨーな文体でぶっちゃけまくってます。 Internet Draft でやるか？一回覗くのオススメ
- 9. 「 __Don't Go Postal__ 」論争と世界観の対立 ソフトウェア的世界観 だって req = doc.RequestPrint() って呼びたいし req.CancelRequest() ってしたいし何が悪いん？ サービスには「固有の機能」を体現する API が あり、それを細かく詰めるのが「よい」設計 （メモ：インタフェース重視） ネットワーク的世界観 「俺様の使い方」で穴を開けられても困るんだよ！ これまでにない使い方をするなら判別できるよう PRINT 命令作るとか配慮してくれないと。 標準化され、明確に定義・分離された形態で 無駄なく通信をするのが「よい」設計 （メモ：管理＋通信効率重視）
- 10. －そしてウェブ的世界観へ－ ウェブ的世界観 固有の「 API 」などない。あるのは固有の URI 群。 それに触ると勝手に固有の処理が進むだけ。 固有の「命令」も不要。送り先が「プリンタ」なら プリント、「ファイル」ならアップロード。 すべては URI であり、管理するのは「手段」よりも 「 URI 」という情報（リソース）そのもの。 「 API 」や「命令」という動詞がほぼ透明に なっていて、情報空間に「もの（情報）」だけが 浮かんでいるのが「よい」設計 ウェブでの「 API 」はかくして追放された
- 11. 衝突＃２：階層構造 in ハイパーメディア フフフ…やる夫様が HTTP を拡張して Writable Web 復権させるんだ～ 次世代のファイルサーバーも作っちゃう～ 鼻息荒いけど、大丈夫か？ じゃあ、まずは質問。コピーって何するの？ そんなの簡単だお！ 元と同内容のファイル構成を作るだけだお！ 予想通り次ページでボコボコ
- 12. ウェブのコピーは甘くない！ （当時出た機能面から UI までの議論） 同じ？ CGI が有効なフォルダと無効なフォルダ間で 「コピー」したらどうなるのが「正しい」の？ 内容の他にも「属性」があるけど、どうなるの？ コピー先が属性サポートしてなかったら失敗するの？ フォルダコピーしたいけど、コピー先が別のサーバー だったらどうすんの？機能のディスカバリできるの？ 別のサーバーってのも「 /foo/bar 」で「 bar 」が 別のサーバーってこともあるんだけど？ フォルダコピーって処理対象の数が判らんから 無限応答待ちで DoS 状態になるかもよ？ もし「 /foo/bar/baz 」で「 bar 」だけ未対応の時、 クライアントはツリー操作画面をどう表示する？
- 13. 階層構造ネックと不採用メソッド一覧 Q: 階層構造の何が問題なのか？ A: 上位要素の操作＝下位要素全部の操作が起きたりする ウェブの単一リソースモデルからの離脱 もうダメだ！ HTTP を拡張しよう！ × これ POST トンネル BATCH マルチ命令 in １命令 × ムリがあるだろ JK… ATOMIC トランザクション的実行 × これって命令数２倍 COPY+NOT 階層 ハイパーリンク的コピー × 同上 COPY+BUT 階層 ファイルシステム的コピー etc, etc...
- 14. 今日の本題：失敗史…ではなく「失敗の効用」 http://www.w3.org/standards/techs/uri これは階層？ ここまでの話、多くの人には「どうでもいい」。 なぜなら「都合の良い幻想を選べる」から。 が、プロトコルという形で２つの世界観を本気で 接続しようとすると、とたんにスキマが明らかに。 重要な点＆今日の主題 「どれが適している」とは別に、この世界観の 衝突が各種の疑問を生み、今日に繋がったこと。 境界が思想の土壌となった。
- 15. 2010 年の境界線： HTTP 拡張からバイパスへ SPDY 、 WebSocket と再び活発化してますが… 衝突の過去・現在 １．階層構造 vs ハイパーリンク構造 ２． RPC-API vs ドキュメントモデル ３ . フロー情報 vs ストック (Addressable) 情報 今ココ 新しい疑問 結局、１～３とも相手は情報空間モデルで共通。 １，２とも「アドレシング」がキーだった。 では、フロー情報の「アドレシング」とは何か？ ここで送出元が「ウェブ」かどうかは問題なのか？ ウェブがフォーカスするのは情報そのもののはず。 アドレス可能性の部分で何か起こる予感…？