• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
The Web That Wasn't - WikiBana #10 LT
 

The Web That Wasn't - WikiBana #10 LT

on

  • 1,709 views

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 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.

Statistics

Views

Total Views
1,709
Views on SlideShare
1,657
Embed Views
52

Actions

Likes
1
Downloads
1
Comments
0

1 Embed 52

http://www.slideshare.net 52

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    The Web That Wasn't - WikiBana #10 LT The Web That Wasn't - WikiBana #10 LT Presentation Transcript

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