JavaScript情報交換所(プログラミング既習者専用) [無断転載禁止]©2ch.net (766レス)
JavaScript情報交換所(プログラミング既習者専用) [無断転載禁止]©2ch.net http://mevius.5ch.net/test/read.cgi/tech/1449440793/
上
下
前次
1-
新
通常表示
512バイト分割
レス栞
抽出解除
必死チェッカー(本家)
(べ)
自ID
レス栞
あぼーん
リロード規制
です。10分ほどで解除するので、
他のブラウザ
へ避難してください。
398: デフォルトの名無しさん [sage] 2016/08/23(火) 00:49:53.34 ID:fTj2N0cj 今のところはそのつもりだ。cscriptと併用する。 Unix使いならcron位自分で書けということでいい。 もちろん他にいい方法が見つかったら変更する。 長期的運用を考えた場合、 ブラウザがクラッシュした時に破損する可能性がある場所はアーカイブとしては使えない。 また他アーカイバも既にあるので、それらとの相互運用を考えた場合も、 生ファイルシステムでないと駄目だ。 格好は悪いがこれが運用上は一番マシだ。 まあもうちょっと考えるが。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/398
400: デフォルトの名無しさん [sage] 2016/08/23(火) 01:17:30.72 ID:fTj2N0cj インストールが必要な時点でアウト。 というかお前は無駄にシステムをでかくする病気にかかっていると思うぞ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/400
406: デフォルトの名無しさん [sage] 2016/08/23(火) 21:49:08.63 ID:fTj2N0cj >>403 おおありがとう。Blobサポート済みか。 となるとボツではなくなった。 記事は古いとは思ったが、政治的案件は時間では解決しないから、どうせ駄目だと思っていた。 >>401 いやcscript併用案はもう既に動いている。 考え方は簡単で、ブラウザで出来ないのはローカルファイルのサポートだから、 それをcscriptにやらせるということ。 とはいえ読み出しには手動で指定が必要だから、それとどっちがマシかということになる。 俺が勘違いしていたFileSystemAPIは ・ブラウザ側で「あるディレクトリ」を指定。これはブラウザ側で手動でしか出来ない。 (指定方法の取り扱いは「ダウンロード」フォルダと同じ) ・そのディレクトリ以下は読み書き自由。 だった。 もちろん生ファイルシステムでOS側からは直接読み書き変更可能。 ブラウザ側からのアクセスはWebアプリ毎にアクセス権が設定されている。 というかこれ以外のFileSystemAPIなんてゴミだろ。 あの糞仕様なら誰も使わない。使う意味無いし。 JavaScript界隈で思うのは、「使ってない奴」「三流プログラマ」が仕様を策定しているということ。 だから「使えない」「使いにくい」仕様が溢れかえっている。FileSystemAPIがゴミなのもこのため。 従来は仕様策定に関われる時点でそれなりの実力者しかいないからこういう事はなかったが、 良くも悪しくもJavaScriptはWebだって事だね。 >>405 つ薬 http://mevius.5ch.net/test/read.cgi/tech/1449440793/406
409: デフォルトの名無しさん [sage] 2016/08/23(火) 23:50:21.90 ID:fTj2N0cj >>407 > exeみたいな実行形式 Webアプリから起動出来なければこれは問題無いだろ。 > OSで特別な意味を表すシステムファイル等 要するにシンボリックリンク等で全部筒抜けになる場合だろ。 これも結局Webアプリ側はブラウザを通しての作成しか出来ないので、それを止めればいいだけ。 OS側からシンボリックリンクを貼ったり、exeを置くのは自由でいい。 Webアプリ側でexeを起動出来ず、シンボリックリンク等を作成出来なければいいだけ。 つまりファイルは「データ」としてしか扱えないという、実装するにも至極簡単な制限でしかない。 FileSystemAPIははっきり言って使う気がない仕様を策定してる。だったら策定しない方がマシ。 まあ策定してから捨てるというのがJavaScript流ではあるようだが。 > IndexedDBやCacheDBの存在で意義をなくしつつある。 結局の所、「勝手に削除される可能性がある」時点でアーカイブとしては使えない。 見たところここを保証する気はなさそうなので、 今回俺がこれらをメインに据えることは出来ないし、 どのみち「削除されない」ストレージも必要になると思う。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/409
410: デフォルトの名無しさん [sage] 2016/08/23(火) 23:50:56.04 ID:fTj2N0cj > Both Microsoft Edge and Mozilla Firefox are implementing the subsets documented in "File and Directory Entries API" for compatibility with Chrome in supporting Directory Upload. 正直これさっさと実装しろというのはある。 ディレクトリ指定出来ればUIが全然簡単になるから。 あとIndexedDBも全然こなれてない。 createObjectStore.oncompleteのタイミングがおかしいのは既に言ったが、(>>394) それとは別にキューの実装もおかしい。 トランザクションがロールバック単位なので、 当初は各リクエストそのままで500トランザクションとか送ったら 「多すぎてキューに入りきりません」とエラーになった。 普通はキューは動的に確保すればいいので、500程度でオーバーフローとかアホかと思ったが、 そんなことを言っていても仕方ないので数珠繋ぎ方式に変更、トランザクションは数個に絞った。 ただそれでもごく偶に、しかも一つ目のトランザクションで同じエラーがでる。 つまり、IndexedDBのキューの実装はバグってる。 なおChrome50。Vistaなのでこれ以上更新出来ないし。 結局の所、大多数が使っている機能じゃないとバグ報告が上がってなくてバグが残っている。 IndexedDBもまだその程度だよ。安心しては使えない。 ただ従来方式の「ダウンロードリンク」を使うにしても、 1日10万ダウンロードとかになるので大丈夫なのか?という疑問はあるが、これも試すしかない。 (ダウンロードは履歴が残るようになっているので、手動ではあり得ないほどの数になると、 履歴がオーバフローするバグが残っているのではないかと恐れている。 これも知ってたら教えて欲しいが。) http://mevius.5ch.net/test/read.cgi/tech/1449440793/410
メモ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.025s