JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net (766ﾚｽ)
JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net http://mevius.5ch.net/test/read.cgi/tech/1449440793/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
365: デフォルトの名無しさん [sage] 2016/08/22(月) 00:02:44.22 ID:m1LOPf7I 中身だけ消す使い方も出来るが、それだと名前対応の辞書引きが必要になる。 管理上「最下層の名前＝最下層のobjectStoreの名前」が一番簡単だからそうしている。 アクセス/追加/廃棄単位もこれと同一だから、管理上はそこにobjectStore階層を置きたい。 もちろんキーに全部含めてフラットに扱うことも出来るが、 元々階層オブジェクトなのをフラットにしてDBに負荷をかけるのは本末転倒だ。 それでコードが楽になるならメリットもあるが、今回はそうではないし。 今回は完全に階層オブジェクト（末端はファイル）だからIndexedDBの必要はないのだけど、 FileSystemAPIだとChromeしか使えない。 これについてはFireFoxはIndexedDBを使えという主張らしく、 確かに機能的には上位互換だから、動作が十分に軽ければ問題ない。だからそれを試している。 https://dev.mozilla.jp/2012/07/why-no-filesystem-api-in-firefox/ http://www.html5rocks.com/ja/tutorials/file/filesystem/ http://mevius.5ch.net/test/read.cgi/tech/1449440793/365
367: デフォルトの名無しさん [sage] 2016/08/22(月) 00:15:46.53 ID:m1LOPf7I >>362 確認した。おそらくそのようだ。 > Transactions of this mode cannot run concurrently with other transactions. Transactions in this mode are known as "upgrade transactions." > https://developer.mozilla.org/ja/docs/Web/API/IDBTransaction そしてこの"upgrade transactions."がどこのプロパティに現れるのか知りたい。 つか、一つならdb.transactionにぶら下げといてくれよなと。 createObjectStoreの後にもここにはぶら下がってないね。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/367
368: デフォルトの名無しさん [sage] 2016/08/22(月) 00:23:12.68 ID:m1LOPf7I >>366 Web上のファイルの保存用途に使う。（アーカイブ） だからファイルが保存出来れば何でも良い。 (まだFileSystemAPIは試していない) URLは最初から階層になっているし、それを保つのが管理上一番楽だからそうする。 したがって、DBアクセスの必要はない。 ユーザがライフタイムを完全に管理出来なければならない。 (Web上から削除された時、ユーザ側で削除するか保存するか決める） CacheStorageはあとで見てみるが、チラ見では新しすぎる感じ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/368
370: デフォルトの名無しさん [sage] 2016/08/22(月) 00:36:42.04 ID:m1LOPf7I >>366 CacheAPI見てみたがライフタイムの管理がよく分からん。 「ユーザ側からの削除無しなら永久保存」（つまりファイルと同じ）に出来る物なの？ https://developer.mozilla.org/ja/docs/Web/API/Cache あとIndexedDBはFireFoxがそういっているから試してみているだけであって、 FileSystemAPIだとWindowsから直接コピーとか出来るはずなので、 結果的にアーカイブの管理が楽にはなるから、そっちを使うかも。 いずれにしても今は試している段階だ。 何か情報あればよろしく。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/370
372: デフォルトの名無しさん [sage] 2016/08/22(月) 00:43:11.87 ID:m1LOPf7I >>369 それも何の負担もないが、 元のURLもクエリを含まないからそのままでも全く負担無いんだよ。 だからその方法ではコードは楽にならない。 仮にFileSystemAPIを使ったとして、 Windowsから直接ファイルをアクセス出来れば、 アーカイブが要らなくなった時にエクスプローラから削除出来るでしょ。 直感的に一番簡単。 それを意味無くフラットなDBにしてしまったら、 そのアプリいちいち起動しないとあれこれ出来ないでしょ。 バグってて削除出来ないとかもあり得るわけでね。そういうこと。 他アプリとインタフェースが揃っているのは重要なんだよ。 仮にIndexedDBも結果的にWindowsファイルの階層として見える形で objectStoreを置いてくれていれば、同様のことが期待出来るわけだし。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/372
373: デフォルトの名無しさん [sage] 2016/08/22(月) 00:49:08.43 ID:m1LOPf7I >>371 出し渋るも糞もアーカイブだと言ってるだろ。 パスはインデックスにするよ。ただしフラットにはしない。 限界サイズはndexedDBよりも多分FileSystemAPIの方が上だ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/373
374: デフォルトの名無しさん [sage] 2016/08/22(月) 00:56:03.75 ID:m1LOPf7I IndexedDBの容量制限は実質1/10*HDDね。 https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria 多分FileSystemAPIには上限がない(HDDの上限だと信じている） 繰り返すが、今回は元々アーカイブ用途だからそもそもDBアクセスの必要はない。 （横断的クエリとか検索とかは全く必要ない） ただ、機能的には上位互換だから動作に問題なければそれでもいい。それだけ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/374
378: デフォルトの名無しさん [sage] 2016/08/22(月) 01:19:31.86 ID:m1LOPf7I >>375 > それに、残念だけど、フォルダとして見られる物じゃないよ。 そうか、これは残念だ。 だったらやっぱりFileSystemAPIかな。 削除機能は内部にも付けるけど、 エクスプローラでも追加/移動/削除出来た方がいいのは自明だろ。 他アプリとの連携もし易くなるし。 まあお前が色々勘違いしているのは分かるけど、 既に言っていることばかりだから読み返してくれ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/378
381: デフォルトの名無しさん [sage] 2016/08/22(月) 01:30:27.67 ID:m1LOPf7I >>377 了解。ありがとう。 アーカイブ用途なのでトランザクションに関しては問題ない。 再ダウンロードして保存すればいいだけだから。 機能は、Web上で削除されたファイルをまだ削除されていないように見せかけるもの。 それが永久だとアーカイブということになる。 CacheAPIは多分この用途に作られているから、 それが使えるのならそっちを使った方が色々すんなり行くのだろうね。 プロキシとして機能してくれるなら、いちいちObjectURLに張り替える必要もなくなるし。 全体として楽になる。 ただ永久保証無しなら、何らかの形で抽出機構が必要になる。 これがちと面倒か。 多分CacheAPIの区画を「永久」「一時」とユーザー側で指定出来れば一番良いのだけど、 無理だよね？ http://mevius.5ch.net/test/read.cgi/tech/1449440793/381
382: デフォルトの名無しさん [sage] 2016/08/22(月) 01:33:03.22 ID:m1LOPf7I >>379 JavaScriptオブジェクトそのまま突っ込めるって話だろ。 もう試したが、今回の用途にはメリットがないんだよ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/382
383: デフォルトの名無しさん [sage] 2016/08/22(月) 01:34:46.91 ID:m1LOPf7I >>379 > だから、FileSystemApiがだよ。 え、マジで？ http://mevius.5ch.net/test/read.cgi/tech/1449440793/383
385: デフォルトの名無しさん [sage] 2016/08/22(月) 01:44:52.41 ID:m1LOPf7I >>384 とりあえず384に書いていることは全部知っているぞ。 ただそんなことせずともURLそのままで保存すれば良いだけなんだよ。 サーバ側でそれなりに考えて階層化されているわけでね。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/385
388: デフォルトの名無しさん [sage] 2016/08/22(月) 02:02:44.31 ID:m1LOPf7I >>386 いや何を勘違いしているのか知らんが、コードはもう動いているし今はテスト中だぞ。 まあそれはさておき、FileSystemAPIが異なるファイルシステムを使っているのは 確定ではないがどうやらそのようだ。 というかこれだとWeb屋は言葉を間違っている。 サンドボックス：その内部で何をやっても外部に影響はない ブラックボックス：その内部がどうなっているか外部からは見えない ブラウザストレージはサンドボックスである必要はあるが、 ブラックボックスである必要はない。というかFileSystemAPIならなおさら。 てかマジでブラックボックスならFileSystemAPIの存在価値無いよ。 これだとFireFoxの言うとおりだと言うことになる。 何で意味無くブラックボックス化してんだ？ http://mevius.5ch.net/test/read.cgi/tech/1449440793/388
390: デフォルトの名無しさん [sage] 2016/08/22(月) 02:22:51.64 ID:m1LOPf7I >>389 いやFileSystemAPIと言うからにはエクスプローラで操作出来ないと駄目だろ。 機能としてはIndexedDBの方が上位互換なんだから、 独自ファイルシステムなら存在価値がない。 > 要はクロームアプリ同士で、ファイルが筒抜けにならんように隔離してみました この必要あるの？ 具体的に言えばアプリのシグネチャ？でも混ぜ込んであるって事？ ローカルストレージが共通なのが多少問題だったから仕切ったってわけか？ http://mevius.5ch.net/test/read.cgi/tech/1449440793/390
391: デフォルトの名無しさん [sage] 2016/08/22(月) 02:50:07.77 ID:m1LOPf7I あー、つかお前らがよく使う言葉思い出したわ。 IndexedDBでもFileSystemAPIでも、 内部データを「追加/移動/削除」する為の機能を自分で作るのは、 「エクスプローラーの再開発」(車輪の再開発）なんだよ。 Windows上のエクスプローラーが使えたらそれが一番良いだろ。 ドラッグアンドドロップやプレビューの機能は全部持っているし、バグもないし。 つか何故いちいち「マイエクスプローラー」を開発しなければならんのよ？ これが>>379の勘違いに対するお前らの言葉での答えね。 そしてChromeは「マイエクスプローラー」の開発を強制するわけだ。 アホかねと。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/391
394: デフォルトの名無しさん [sage] 2016/08/22(月) 21:30:14.52 ID:m1LOPf7I すまぬ、>>358は間違い。 upgradeのときはe.target.transactionが最初から入っている。 昨日も確認したのだが、どうやら間違えたようだ。 これで修正出来たかは確認中。 これとは別に、createObjectStoreのoncompleteが少し早いタイミングで返ってくるらしく、 oncomplete直後にput等をせずに終了するとエラーになる。 これはupgradeのtransactionが並列出来ないということなので、 一旦closeして開きなおして並列性を高めようとしたが、失敗した。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/394
395: デフォルトの名無しさん [sage] 2016/08/22(月) 21:40:34.14 ID:m1LOPf7I >>392 未来のストレージがどうなるかは別の話だ。 FileSystemAPIはオレオレエクスプローラの再開発をしなくて良いのが利点であって、 それがないのならゴミでしかない。 お前が色々再開発をするのは勝手だけど、大多数の人にとっては、 普段使っている物がそのまま使えるのが一番分かりやすいUIだ。 Webアプリ間での相互アクセスを禁止するのはいいとして、 OSからの透過アクセスを禁止する意味はない。 ブラウザアプリからは常にブラウザ経由になるのだから、 アクセス権限、unixで言う644とか755とかを管理するのが一番簡単。 何でそんな糞仕様にしたのか意味不明。 ていうかChromeではBlobをIndexedDBにいれれないのか。使えねえ。 IndexedDBで両対応という作戦は頓挫した。根本的に練り直しだ。 てかマジでこの辺統一しろよな。 > While Firefox supports blob storage for IndexedDB, > Chrome currently does not (Chrome is still implementing support for blob storage in IndexedDB). > If you are targeting Chrome for your app and you want to store blobs, > the File System API and App Cache are your only choices. > However, AppCache storage isn't locally mutable, > and doesn't allow for fine-grained client-side management. > https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Introduction http://mevius.5ch.net/test/read.cgi/tech/1449440793/395
396: デフォルトの名無しさん [sage] 2016/08/22(月) 21:41:45.37 ID:m1LOPf7I >>393 それはお前が無能だからお前の周りも無能しかいないだけ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/396
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.039s