アカウント名:
パスワード:
Market Placeはわかるし、Appもわかるが、Web Appとはなんだろ?ブラウザ表示可能なら、別にWindowsであろうが、Macであろうが関係ないと思うけど。環境依存型ブラウザのプラグイン?
逆だね。w3cの言ってるwebappsのことでしょ。環境非依存でかつデリケートな処理って感じ。
既に標準化されているのなら、クリップボード: http://www.w3.org/TR/clipboard-apis/ [w3.org]File API: http://www.w3.org/TR/FileAPI/ [w3.org]バッテリー残量: http://www.w3.org/TR/battery-status/ [w3.org]できつつあるのなら、IME API: http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html [w3.org]フルスクリーン API: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html [w3.org]ゲームパッド API: http://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html [w3.org]とかがそう。
デスクトップアプリケーションでクリップボードの監視もできないようなら、メモ帳に毛が生えたようなやつですら作れない。そこを乗り越えるためには、「ユーザーが許可した場合のみクリップボードのアクセス権」を与える、っていうことが必要になるんだけど、メモ帳の操作の度にクリップボードのアクセス権を設定するようなのは、ウェブサイトとしてもデスクトップアプリケーションとしてもダメだ。
だから、呼び方は「購入」でも「インストール」でもいいんだけど、最初の導入時にユーザーに意思表示させて、以降はそのファイル(というか名札)そのものを信用するっていう手続きが必要になる。まあ、普通のデスクトップアプリケーションでも普通にやってることだけど。
で、このアプリケーションの実行環境(シェル)がブラウザなんだよ。だから、プログラマはウィンドウの代わりに<iframe>とか書くわけ。基本的に全てのプログラムはスクリプト言語で書かれていて、UIはhtmlとDOMで操作する。ここまでは普通のウェブサイトと一緒だけど、普通のウェブサイトが使うAPI(=生のJavaScriptとDOM)よりは高い権限が必要なはずのAPIが使える。そのAPIは勝手APIじゃなくて、標準化されているから、逆に、そのAPIが実装されていれば、どの実行環境(=ブラウザ)でもアプリケーションが動く。さらに、見た目もデスクトップのテーマに合わせるから、普通のアプリケーションみたいになる。 https://wiki.mozilla.org/Apps/WebRT [mozilla.org]
プログラマはスクリプトからAPIを呼ぶことしかできないから、生のコードに近い部分では何もできない。そういう意味では、拡張機能やプラグインみたいにプログラマが信用されているわけではない。
まあ、アプリケーションそのものはともかく、インストール方法は当面標準化されないだろうから、今のところは互換性を云々するレベルじゃない。でも最初にwebappsを言い出したのはOperaとかあのへんだから、そのうちある程度までは標準化されるんじゃないの。
標準化中のリストwebapps:http://www.w3.org/2008/webapps/wiki/PubStatus#Widget_Specifications [w3.org]:Device API(=スマホのハード絡み)http://www.w3.org/2009/dap/ [w3.org]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
環境依存のWeb App??? (スコア:0)
Market Placeはわかるし、Appもわかるが、Web Appとはなんだろ?
ブラウザ表示可能なら、別にWindowsであろうが、Macであろうが関係ないと思うけど。
環境依存型ブラウザのプラグイン?
Re:環境依存のWeb App??? (スコア:0)
逆だね。w3cの言ってるwebappsのことでしょ。環境非依存でかつデリケートな処理って感じ。
既に標準化されているのなら、
クリップボード: http://www.w3.org/TR/clipboard-apis/ [w3.org]
File API: http://www.w3.org/TR/FileAPI/ [w3.org]
バッテリー残量: http://www.w3.org/TR/battery-status/ [w3.org]
できつつあるのなら、
IME API: http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html [w3.org]
フルスクリーン API: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html [w3.org]
ゲームパッド API: http://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html [w3.org]
とかがそう。
デスクトップアプリケーションでクリップボードの監視もできないようなら、メモ帳に毛が生えたようなやつですら作れない。そこを乗り越えるためには、「ユーザーが許可した場合のみクリップボードのアクセス権」を与える、っていうことが必要になるんだけど、メモ帳の操作の度にクリップボードのアクセス権を設定するようなのは、ウェブサイトとしてもデスクトップアプリケーションとしてもダメだ。
だから、呼び方は「購入」でも「インストール」でもいいんだけど、最初の導入時にユーザーに意思表示させて、以降はそのファイル(というか名札)そのものを信用するっていう手続きが必要になる。まあ、普通のデスクトップアプリケーションでも普通にやってることだけど。
で、このアプリケーションの実行環境(シェル)がブラウザなんだよ。だから、プログラマはウィンドウの代わりに<iframe>とか書くわけ。基本的に全てのプログラムはスクリプト言語で書かれていて、UIはhtmlとDOMで操作する。ここまでは普通のウェブサイトと一緒だけど、普通のウェブサイトが使うAPI(=生のJavaScriptとDOM)よりは高い権限が必要なはずのAPIが使える。そのAPIは勝手APIじゃなくて、標準化されているから、逆に、そのAPIが実装されていれば、どの実行環境(=ブラウザ)でもアプリケーションが動く。さらに、見た目もデスクトップのテーマに合わせるから、普通のアプリケーションみたいになる。 https://wiki.mozilla.org/Apps/WebRT [mozilla.org]
プログラマはスクリプトからAPIを呼ぶことしかできないから、生のコードに近い部分では何もできない。そういう意味では、拡張機能やプラグインみたいにプログラマが信用されているわけではない。
まあ、アプリケーションそのものはともかく、インストール方法は当面標準化されないだろうから、今のところは互換性を云々するレベルじゃない。でも最初にwebappsを言い出したのはOperaとかあのへんだから、そのうちある程度までは標準化されるんじゃないの。
標準化中のリスト
webapps:
http://www.w3.org/2008/webapps/wiki/PubStatus#Widget_Specifications [w3.org]:
Device API(=スマホのハード絡み)
http://www.w3.org/2009/dap/ [w3.org]