Web ベースのオーディオ エディタの概念モデルを構築中です。そして最初に遭遇した問題は、クライアント側のキャッシング システムです。私の意見では、クライアント側に巨大なキャッシュを持つサーバー側プログラマーは完璧なアイデアです。多くの場合、同じデータの複数回の読み込みを除外することでサーバーの負荷がかかるためです。さらに、このようなキャッシュは、フィルタリングなどのトラックごとの操作を提供するためのバッファとして適している可能性があります。
私たちのフレックスプログラマーは、これは大きな問題であり、ほとんどの場合不可能であると言います. しかし、実際の Google Chrome ブラウザーのバージョンは、localStorage に最大 2 Gb まで簡単に保持できることを知っているため、私は大きな疑問を抱いています。さらに、このオンライン トラック エディタの例を見つけましたが、そのキャッシング メカニズムはかなりうまく機能しているようです。
フラッシュと js を使用して、クライアント側で一部のデータ (約 100 ～ 200 MB) をキャッシュすることは可能ですか?
SharedObject を使用してデータを格納できます。
デフォルトのサイズ制限がニーズに対して小さすぎると確信しているため、アプリはユーザーに新しい制限を受け入れるように求める必要があります:
http://www.macromedia.com/support/documentation/en/flashplayer/help/help06 .html
SharedObject はブラウザーのキャッシュよりも信頼性が高く、アプリから制御できます。
If you are using html5 then you can store large data on client side using html5 inbuilt database.
also refer this link
ビデオ エディタを作成するときに行ったこと。実際には、Flash ではファイルをユーザーのマシンに保存できますが、ユーザーに対して透過的でなければならないという制限があります (つまり、ユーザーはアクションを開始し、OS ダイアログを通過し、通常は何でも保存するようにファイルを保存します)。同様に、ユーザーのコンピューターからファイルを読み込むことができますが、ユーザーがアクションを開始する必要があるという制限があります (ポインティング デバイスでクリックするか、キーを押すなど)。
これには、ユーザーにとってほとんど不透明なさまざまなローカル ストレージ戦略よりも一定の利点があります (人々は通常、最新のブラウザーに付属する Cookie、SharedObjects、または Web ストレージを消去する方法を知りませんが、それらを保存および削除することはほとんど可能です)。システム上のファイル)。さらに、他のすべての不透明なローカルストレージには、あまり知識のないユーザーが克服する方法がわからない、または一般的に克服できない可能性があるという制限があります。これらは、サイズ、場所、および所有権です。
ファイルを保存する必要があるたびに、Ctrl + S / Cmd + S / Cx Csを実行する代わりに、OSのダイアログを通過する必要があるため、これは聴衆にとってはまだ少し邪魔になります.他のオプション、これ、IMOは、ユーザーに最も多くの選択肢を残します/最高のエクスペリエンスを提供します.
別の提案 - 原則として、ユーザーがブラウザ プラグインとしてインストールするアプリケーションのブラウザ ベースの「拡張」バージョンを考え出すことができます (それが定期的に使用しているエディタである場合は、なぜですか?)。その場合、Web テクノロジによって提供されるぎこちないオプションに制限されることはありません。Chrome および Mozilla ベースのブラウザーはこのような開発を奨励していますが、標準化されていません。それでも、これら 2 つのブラウザはほぼすべての OS で動作するため、ユーザーを特定のプラットフォームに閉じ込めているとは特に思えません...