@tacumi メモリだけでいってもが、たとえばかつてのSunのシンクライアントが積んでたメモリと、現在のウェブブラウザがウェブ越しにオフィススイートを実行するために要求するメモリ、どちらが大きいでしょう？＞＜

@[email protected] それを言うなら今のオフィスソフトが実現しなきゃいけない機能にどれだけのメモリが必要かまで考えて言ってるんだね?
当時はそれを行うことができないから機能を制限せざるを得なかったという背景まで考えて.

@tacumi どう必要な機能が増えてるんでしょう？＞＜
たとえばDEC Alphaがまだ元気だった時代に既にスペルチェックに秒単位の時間がかかる時代は通り過ぎてるんですよ？＞＜

@[email protected] 複数人が同じドキュメントを操作する機能は今はブラウザ上では必要でしょう?そのためにはリアルタイムでクライアント側の操作を同期させるための処理が走るはずで,そのために必要なメモリが増加することは避けられないと思うのですが

@tacumi あなたはそれにどのくらいの単位のメモリを見積もります？＞＜
オレンジは、それに100MB以上追加で必要になったら、それは実装の設計が根本的に間違えていると考えて立ち止まって検証しますよ＞＜

@[email protected]
もっかい議論の始めまでもどりましょっか
なんかズレてる気がしはじめた.

あなたは「ウェブブラウザがIDEよりオフィスソフトよりメモリを食うのが問題だと思う」と言ってましたね
それに対して自分は「オフィスソフトがウェブブラウザ経由で利用される現在ならそれはそうだろう」という意味の返答を返したんですが,ここまでで理解の相違はありますか

@tacumi たぶん＞＜
シンクライアントを例に出した通り、サーバー側にリソースを押し付けられるだろうにより多く消費しているということは、実装に問題があり、ひとつのドキュメントを複数人で操作する機能ごときでクライアントの要求メモリが大きく上昇するのは、サーバーに処理を任せるモデルではなおさら実装が間違ってると言えるかも＞＜
あるいは、そもそもウェブブラウザ越しというモデルが正しくなかったかのどちらかかも＞＜

@[email protected] 複数人が同時に同じドキュメントを操作することがかなり難しいのでそれを無理矢理実現するならそうなるなと思います

@tacumi なぜせっかく鯖があるモデルで実装してるのに、全体の調停と合成に関する処理をクライアントに押し付ける必要があるのか？＞＜ そうやって考えていけば純粋にそれにより追加されるヒューマンインタフェース(鯖側とに調停含む(もっともそれはこの機能がなくても必要))が必要とするリソース以上のリソースを消費したら実装がおかしいと気づけるかも＞＜