COM や OLE という視点でいくと、オープンソース陣営よりも
Microsoft 陣営のほうがはるかに進んでいると思う。
私は普段ほとんど Linux ばっかり使っているが、
Linux のソフト同士は協調するのが難しいと思う。
(ほとんどのソフトがライブラリレベルの機能共有とか
パイプでの連携程度にとどまっている。
オブジェクトとして連携できないものがほとんどだと思う)
Windows には COM で協調することで、ソフト同士が
連携しやすりという点においては、オープンソース陣営よりも
進んでいると思う。
GNOME や KDE にしても、オブジェクト連携においては
はるか昔の Windows の技術のレベルだと思う。
# Linux にも COM (CORBA でもいいけど) みたいなもので
# もっとソフト同士が連携できると楽しそうだなぁと思うこのごろ
Component Object Model (スコア:1)
Microsoft 陣営のほうがはるかに進んでいると思う。
私は普段ほとんど Linux ばっかり使っているが、
Linux のソフト同士は協調するのが難しいと思う。
(ほとんどのソフトがライブラリレベルの機能共有とか
パイプでの連携程度にとどまっている。
オブジェクトとして連携できないものがほとんどだと思う)
Windows には COM で協調することで、ソフト同士が
連携しやすりという点においては、オープンソース陣営よりも
進んでいると思う。
GNOME や KDE にしても、オブジェクト連携においては
はるか昔の Windows の技術のレベルだと思う。
# Linux にも COM (CORBA でもいいけど) みたいなもので
# もっとソフト同士が連携できると楽しそうだなぁと思うこのごろ
落とし穴: message passingによる性能劣化 (スコア:2, 興味深い)
COMのようなcomponent technologyは一部ではcode再利用などのご利益があったものの、実はperformanceを犠牲にしているという問題があります。
processや計算機の境界を超えたprocedure callというと思い出すのはMachですが、これについて最近びっくりする話を聞きました。実はMachはmessage passingの性能を上げるために、hardwareでそれを行っていたというのです(by Terry Lambert)。よくよく考えれば、processorのcall命令(あるいは相当物)と同じ程度までmessage passingのcostを切り詰めないと、message passingが性能の足を引っ張ってしまいます。Machのころはこの差が顕著に現れた(それゆえにMachは全体では使いものにならなかった)のですが、今ではあまり気にしなくなったのか、高い金を出してprocessor能力のほとんどをprocedure callに費やすことが多くなっています。
選択肢を残すという点では、Unix-likeなOSにはむしろ計算機のperformanceをそのままuserに使わせてあげることに専念して欲しいですね。
Re:落とし穴: message passingによる性能劣化 (スコア:1)
>Unix-likeなOSにはむしろ計算機のperformanceをそのままuserに使わせてあげることに専念して欲しい
userに何を「させてあげられ得る」のか?という点では、unixのモデルには、ちと不安を感じています。
前述したとおり「unixにはviを作る力が無い(あれはC言語に有るのです(^^;)」のであって、
unixモデルの範囲で(楽に)やれることの範囲ってのは、結構狭いように感じるのです。
ゲイツ実装がそういうモノであるかどうかとは独立に、
もともとのコンポーネントモデルってものは、viを作れる(^^;モデルであるわけです。
エディタのように、各部品が「緊密に」状態情報を相互にやりとりしないと作れないソフトを、です。
unix部品化(=パイプ)モデルで、ObserverPatternを組めるもんなら組んでみてくださいって感じ。
もちろん効率の低いアクロバットは却下として。
そもそも「同一のインスタンスへコールバックする」という概念で、つまずいてしまうはずです。
その限界を超えるには、unixモデルの中では本質的に、ごりごり書くしか無いわけで。
じゃあ(unix上でvi的なものを作れる)GNOMEなりなんなりが何をやっているか?というと、
unixの枠とは無関係な世界をいったん築いて、その上でやっているわけですから、
あれはunixの手柄ではない。
MSになんらかの革新の手柄が有ったとは思えませんし、実装も色々腐ってるようですが(^^;、
原則としてwinには、unixよりは「ちょっと進んだ(=革新済みの)便利なもの」が入っているってのは、事実かも。
よだん:
プロセス壁超えがコンポモデルと常にツガイであるとも限らないのでよろしく。
なんかマイナーですが(^^;、delphi/kylixのモデル(あくまで実態はクラスライブラリでしかない)だって、それなりにコンポモデルであるはずです。
というか、いつの間にコンポという言葉が壁超えの意味を内包するようになったんだろう?
ここ数年の「コンポ」という言葉のブームよりは、delphiのほうがちょっと先輩だと思うんだけどなあ(^^;
Re:落とし穴: message passingによる性能劣化 (スコア:0)
そもそも、pipeでviはつくれないってのじたいが、言いがかりっぽい。 UNIXは部品の組み合わせで今自分がやりたい処理を簡単に 行うことができる、ってのがツールキットアプローチであって、 部品を組み合わせて簡単にアプリが作れるなんていうのが UNIXの利点だなんて誰も言ったのか?
既存部品+少しの新規コード+糊
という図式を考えるとして、UNIXの場合は、 既存部品=フィルタ・ツール、糊=pipe なわけですが、 これでviのようなものが作れないのは確かにそ
Re:落とし穴: message passingによる性能劣化 (スコア:1)
>UNIXは部品の組み合わせで今自分がやりたい処理を簡単に
>行うことができる、ってのがツールキットアプローチであって、部品を組み合わせて簡単にアプリが作れるなんていうのが UNIXの
>利点だなんて誰も言ったのか?
いや、それは「unix(勢)が言うところのToolkitApproach」の定義に過ぎないと思いますよ。
状態モデルてゆーかObjectぽいものをサポートしてないToolkitApproachだ、ということ。
で、ObjectっぽいものをサポートしたToolkitApproachというものも、また別途ありえると思うのですが、どうでしょう?
もちろん、どんな定義であろうとそれはそれなのですが、実際には、サポートする範囲が狭い定義(に基づいた実装)は
当然ながら不便であるわけです。両者の間には、しばしば、はっきりした優劣が有るはずです。
で、Objectっぽいモデルを使ってpipeっぽいモデルを代用することは容易ですが、逆は困難です。
言ってしまえば、簡単にアプリが作れないことを以って、unixのやりかたは(ここで言ってるやり方より)劣ってる、と言えるはずです。
わが道を行くぞと言うのは自由ですが、そう主張する「価値」は低い、ということです。実用性において劣っているのですから。
古いシステムだからそういうものをサポートしてなくても「当然」だといえるのは確かですが、
だからって(相対的)存在価値が今もなお変わっていないか?というと、そうは言えないはずです。
なお、「処理」と「アプリ」の差は何だ?という問題がありますね。
少なくとも俺は、「処理の可能性(ability)の束」がアプリである、と定義して良いと思います。
というか、両者を必要(?)以上に別物あつかいしたがるのは、悪い意味でのunix的考え方だなーと思います。
両者を統合して考える能力が無い環境だからこそ、別物だと考えざるを得ない、というわけです。
unixでも、望む処理の羅列をscriptという形で永続化できるわけですが、その方法論の延長で
「状態モデル込みの処理」のパターンを(しばしば複数束ねて)、永続化できるならば、
それ即ちアプリになり得たはずです。でもunixはそうしなかった。
#Tcl/Tkとか使えば、そういうものを作ることは出来ますが、それにOSは何も貢献していないので、ここでは論外。
さて。
>一度、本物のviを作って見せてくれよ。できたら信用してやる。stevieとかvip-modeみたいな偽物はダメよ。
>つまり、何が言いたいかというとエディタの場合、バリエーションがありすぎる。既存部品が使えないだろうってこと。
うわ。そういう要望ですか。なんだかなあ。
それ言い出したら、「あらゆる部品化アプローチ(勿論unix方式も)」について、悲観的に捉えざるを得なくなるだけなんですが…
まあいいでしょう。結論からいえば、今そういう実装が有るかどうかは別(^^;として、原理的には可能です。
どうすればいいかというと、viというものを「分解」するんです。
たとえば、キーバインドを司るObjectは、表示Objectとは、別物としておく。
モードを司るものも、データを貯めるもの(Buffer?)も、Lisp処理系(^^;も、全部別々のObjectにする。
そして、それらを「接続」するんです。
部品は好きなものを選べばいいでしょう。viじゃなくEmacsなキーバインドを司るObjectに差し替えれば
そのエディタのキーバインドはEmacsになるはず。純正viもstevieもなんでも有りでしょう。
もちろん、そういう着脱可能な細かい部品を自由に接続して運用できるようにするには、
なんらかのインターフェース規約を先に作らないと駄目ですが、
そういうのは仕様違いをラップするObjectを挟むことだって出来るので、まぁ後からなんとでもなるでしょう。
ちなみに言えば、この「部品が接続されたパターン」が、古典的にいう「アプリ」に相当するものになるはずです。
余談:
「Unixをもう少しましなものにしよう」 ( 本文和訳はこちら [os-omicron.org]、 Tikiで議論(^^;はこちら [os-omicron.org])
に有るように、部品化はもっと意識したいものです。
まぁプロプラ云々という台詞は「信じたくはない」ですけども、だからこそ尚更、
プロプラなんかに頼らずに、現代的な部品化の仕組みを大成させたいものだと思うのです。
部品化から背を向けるのはイタイだけっす。
> エディタは部品を組み合わせることでちょいちょいと作れるという例には当てはまらない
じゃ、 (スコア:0)
昔メリット、今デメリット (スコア:2, 興味深い)
よく日本でUnixをやっている人に見受けられるのですが、昔メリットだったことが今やデメリットになっていることに全く気づかないことがあります。Xもnfsも高機能な機器が高価だった昔はネットワークを通すことに意味がありました。しかしPCやらHDDがたたき売りされる今、帯域を求めたらネットワークなんてハナっから対象外です。それで例えばXでもMIT shmのようにネットワークを否定するような拡張をせざるを得ませんでした。
それでも分からない人には、この事実を突きつけておきましょう。4.2BSDが採用したsoftware interruptは当時の小さなmessage queueにとってはこの上ない機能でした。それが今や高速に終わらせるべきpacket処理を頻繁に横取りさせる原因となり、receive livelockの元凶 [harvard.edu](DoS攻撃による直接の影響)となっているのです。
Re:昔メリット、今デメリット (スコア:2, 興味深い)
その逆転の論理が正しいとしたら、それはまたちょっとした皮肉ですね。unixに対しての。
なまじ高速なデバイスが有る時代に、却って帯域を「いかに空けるか」を気にしないとならないのですから(^^;、という皮肉もさることながら、
もっと皮肉なのは、「ネットワークが邪魔なら、(unixご自慢の)プロセスの壁だって、邪魔じゃん?」という点だと思うのです。
実際、共有メモリ(shm)で穴あけるってのは、プロセス壁の邪魔を(も)嫌った結果なわけでしょ?
また、最近流行のweb鯖では、1リクエストに1プロセスというモデルでCGIやってたら
日が暮れるのは判りきっているわけで、同一プロセス内でマルチスレッドこんにちわな時代になっちゃった、と。
#そういう状況では、本当はプロセスなんか要らないんだけど、たまたまOSはそういうモデルしか提供してないので、間借りしてるだけ。
というわけで、unixの根幹(だよね?)である「プロセスモデル」もまた、
「昔メリット、今デメリット」攻撃の矢面に立たされているんだなーと認識しています。
なお、プログラム(アプリ?)をobject単位で部品化する際、
それと同時にネットワーク透過モデルを導入する必要が有るのかどうか?については、
実は「どっちでも良い」ってのが答えだと思います。
なので、コンポーネントモデルを批判する際、できるならば、ネットワーク透過性への批判を、同時に込めないで頂けると、個人的に嬉しいです。
まぁ今回はCOMという1実装の話題なんでアレですが。
Re:昔メリット、今デメリット (スコア:1)
簡単に分かることだけ。
たとえもっとも安価とされているuser-level threadを用いたとしても、one thread per requestでやっていては結局processをforkするのと全く変わりません(そのthreadが全く関係ない別のrequestに使い回されてしまう恐れがある、これは不必要な遅延を招くだけ)。httpの場合、本質的に効率を改善してくれるのはkeep-aliveによってapplication layerでのpollingを実現することです。これを実現すればprocessを使っていてもかなりthroughputが上がります。
processがどうこうというのは特定のOS、すなわちsoftwareに依存した問題に過ぎません。片や割込みのschedulingはethernet chipから冷蔵庫並みの汎用機にまで、物理層からapplication layerにまで共通する、全く別の問題であることをお忘れなく。
Re:昔メリット、今デメリット (スコア:1)
>forkするのと全く変わりません(そのthreadが全く関係ない別のrequestに使い回されてしまう恐れがある、これは不必要な遅延
遅延がどうこういう以前に、one per oneでは、複数リクエストが鯖内で混線しそうです。
それじゃ論外なので、そういう話題ではないと思います。
>httpの場合、本質的に効率を改善してくれるのはkeep-aliveによってapplication layerでのpollingを実現することで
>す。これを実現すればprocessを使っていてもかなりthroughputが上がります。
今回の文脈では、俺はどっちかってーとthreadの(pollingならぬ(^^;)poolingのほうを思い出します、効率改善の手法としては。
#ついでにいえば、webアプリを例にしましたが、HTTPに依存する問題を語りたかったわけじゃないです。
##もちろんHTTP側も別途最適化してくれることは望ましいですが。
たぶん、threadを生成しておいて、必要になったらそれを「使い」、リクエスト処理が終わって不要になったら「返す」、
ってことを普通やりますよね。
#当然ですがその際に、不当な使いまわしはしないように仕掛けを組みますよね。使用中のthreadは他から同時に使用されないようにするっつー。
#もちろん必要なContextも使いまわさないようにします。共有データとリクエスト別データとはきちんと分けます。
##って、この辺の話は、ふつーのJavaServletの話ですが。
>processがどうこうというのは特定のOS、すなわちsoftwareに依存した問題に過ぎません。片や割込みのschedulingはethernet
>chipから冷蔵庫並みの汎用機にまで、物理層からapplication layerにまで共通する、全く別の問題であることをお忘れなく。
あれ?今回って、いつからschedulingの話題になったんでしたっけ?
どっちかというと、COM(というか一般的にObjectモデル)を持つWinと、持たざる我らが(free)unixと、
の比較という文脈だったように思うのですが。
そして、効率の話をするときは、本質論が全てに優先するとは言い切れないのは、(きっと)ご存知の通り。
processもthreadもscheduling対象物という意味では同じでしょうけど、ここではむしろ両者の差異のほうが問題になるはずですよね…
Re:落とし穴: message passingによる性能劣化 (スコア:0)
それは全ての場合ではないです。in processな場合は関数呼び出しとほとんど同じ程度のオーバヘッドですし、オートメーションをサポー
OLEの悪夢 (スコア:1)
以前、自作のアプリケーションにOLEインプレースサーバ機能(*)を付加しようとしたことがあったんですが、自社製アプリケーションやワードパッド、MS-Wordに対しては問題ないのに、Excelに貼り付けたときだけ、起動時にExcelごとお亡くなりになるという症状が出て困りました(^^;)
どうやらウィンドウのIDがバッティングしているらしかったのですが、どうにも解決のしようがなかったため、泣く泣くインプレースは諦めました。
(InsideOLEとかも役に立たず)
あのときは切実に、「Excelのソースが欲しい…」と思いましたね(笑)
結局バルマー氏が言いたいのは、「技術革新には金がかかる。オープンソースは金にならん」ってことなんじゃないかと感じます。
実際、もし仮にMSのOSやアプリケーションがオープンソースだったとしたら、開発者にとってはありがたいと思えるのですが…。
(別にパクったりしないからさぁ…(^^;))
*OLEインプレースサーバ : コンテナアプリケーションのウィンドウ内に、サーバアプリケーションが埋め込まれて起動するやつ。
Re:OLEの悪夢 (スコア:0)
Re:OLEの悪夢 (スコア:0)
Re:Component Object Model (スコア:0)
Re:Component Object Model (スコア:0)
OLE → ActiveX → COM → COM+ → (MFC) → (ATL) → .Net
でしたっけ?
どれも悪夢でしかないんですが。
Re:Component Object Model (スコア:1)
ほんとうに横並び?という気がしますが。
OLEの前のDDEは忘れちゃいました?
今時、DDEの部品作ってましたと言っても通じないか。
仕事では、ATL3.0でCOMを作ったのが最後。
最近は、C#と.Net Frameworkが遊ぶのにちょうどよさそう。
仕事で移植はしたく無いなりヨ。
>どれも悪夢でしかないんですが
悪夢なのは、1つを覚えても1、2年後にはテクニックが
変わってしまうことでは?
Re:Component Object Model (スコア:1, 参考になる)
OCXとかDCOMとかも抜けてる。OLEはOLE2でCOMと合体。OCXはOLE/COMベースでコントロールを扱えるようにした代物、ActiveXはOCXをインターネット対応したもの、DCOMは分散拡張したCOM、COM+はトランザクションみたいなの(?!)、これらをすっきりさせて実装をみせなくし、扱いの煩雑さを払拭したのが.NET。
MFCとATLはコンポーネントとは直接的には関係ないです。COMのラッパをサポートしてるだけ。
Re:Component Object Model (スコア:0)
だから、悪夢だったんでしょうね。
もっと理解していれば、別に仕事として淡々とこなせていたんじゃないでしょうか。
Re:Component Object Model (スコア:0)
> もっと理解していれば、別に仕事として淡々とこなせていたんじゃないでしょうか。
いやいや、理解しにくいわ、また新しいのでてくるわで
やっぱり、淡々と・・・とはいけないのでは?
むしろ、淡々としている姿勢に問題がありそう。
Re:Component Object Model (スコア:0)
アプリケーションの1つにすぎないと言う割にはOSと分離するのが
ものすごく面倒な代物。
富豪的な考え方でいけばプロセス間通信でいいわけで。
Re:Component Object Model (スコア:2, 興味深い)
ところで、あれはMSの実装が、「どこに」どんな部品を置き、「どこから」それを参照するか?という設計について
(意図的かもしれぬ)ミスをした結果であって、
部品化の枠組自体がおかしいわけじゃない、とは思いますよ。
#やっぱJavaOS流行らねーかな?(笑)
#といっても、Javaでwebアプリ鯖やれば、既にほとんど同じようなものだが。
>富豪的な考え方でいけばプロセス間通信でいいわけで。
富豪すぎます(^^;。具体的に言えば重すぎます。
unix pipeみたいな、一方通行かつ経路一本だけ(なので同期処理オンリーで賄える)というモデルならそれでもいいんですが、
objectな人々が当然のように(^^;やっている、相互参照相互呼びだしアリーの、経路複数アリーのの世界では、
とてもじゃないけどやってられません。
状態モデルを「やりとり(一方通行じゃなく)」するモデルを採用「したい」場合、
unix方式は、効率は出ないし、プログラミングも面倒になるばかりです。
俺はこれを象徴的に、「unixの部品化モデルでは、viエディタを作れない」と呼ぶことにしています。
#エディタは上記モデルを採用「したい」古典的かつ典型的な例です。
#つまりそういう需要を「無くそうと努力」するのも無駄だということです。
あ。すみません。プロセス間通信ってことは、unixの部品化モデルを「使わない」という話ですね。
ああ。使わないのか。そりゃまあ使えないもんなあ、unixのアレは…(笑)
>アプリケーションを細切れにしてOSと混ぜ合わせて
御存知のとおり、状態モデルの「インスタンス」が(メモリ空間の)何処に存在するか?と、
ルーチンが何処に存在するか?とは、本来は別問題です。
#まぁゲイツがそれらを混同したかどうかは更に別問題ですが(^^;
なので、「OSと混ぜた」といっても、それが「ルーチンの」相乗りなのか、「インスタンスの」相乗りなのか?は、
区別しないと変な話になります。
Re:Component Object Model (スコア:0)
実行時の状態がどういうものになるか、はここでは考えていません
でしたね。アプリケーションをどのように提供するか、ということに
ついて、IE4.0以降(だったかな)では、これまでにないような方法を
とったわけですし、そこがこの話の主眼(MSによる技術革新)かと
思ってます。
OSとアプリケーションが共通の部品を使う、インスタンスが共通な
だけでなく、部品そのものが共通(~.dll
Re:Component Object Model (スコア:1)
>だけでなく、部品そのものが共通(~.dllみたいなヤツ)で、
あっと。ちょっと順序が逆かな。
winがそうなのかどうかは知りませんが、
インスタンスが共有されていなくても、ライブラリ(.dllとか)が双方で使われている、
ということは有ります。
ライブラリはOOPでいうクラスみたいなものですから、そのクラスから
「別個の」インスタンスをそれぞれ生成することは幾らでもできますし、
たまたまそれが片やカーネル空間で片やユーザープロセスの中で、
ということは有り得るでしょうね。
もっとも、カーネル空間でインスタンスを生成するとヤバいようなクラスのインスタンスをカーネル空間で生成しちゃえば
そりゃおかしいことになるでしょう(てーかwinがもしかするとまさにソレなのかな…) が、
それはちょっと別の問題なので。
逆に、インスタンスが共通でクラスが違う、ってことは普通は無いはずですよね。
#「部品」という語がクラスを指すのかインスタンスを指すのか、は状況次第であり、状況ごとにハッキリさせとかんと話が混乱しますぅ。
Re:Component Object Model (スコア:0)