In article <87psvxn...@taito.co.jp>
takahide nojima <noj...@taito.co.jp> writes:
> WindowsでCORBA使えるんですな...知らなかったです。
> http://www.02.246.ne.jp/~torutk/cxx/corba/
CORBA やるくらいなら、SunRPC (ONCRPC)でいいんじゃないですか。
昔、Windows から NIS をたたくのに使ったことがあります。
うちの若いのは、自分で RPC のライブラリを書いたみたい。スタ
ブ生成器はないので、スタブは手書き。数がすくなければ手書きも
たいしたことはないです。htonl() して write() とか、そんな感じ。
\\ 新城 靖 (しんじょう やすし) \\
\\ 筑波大学 電子・情報 \\
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> CORBA やるくらいなら、SunRPC (ONCRPC)でいいんじゃないですか。
> 昔、Windows から NIS をたたくのに使ったことがあります。
>
> うちの若いのは、自分で RPC のライブラリを書いたみたい。スタ
> ブ生成器はないので、スタブは手書き。数がすくなければ手書きも
> たいしたことはないです。htonl() して write() とか、そんな感じ。
なるほどです。まあ、CORBA実装のWin環境はOSSなものを見つけたので
「少々大げさかな?」とは思うものの利用のハードルは低そうな
気がしてます。
どなたかWin環境のSunRPCを誰か作って公開してないかなーと思うこのごろです。
CORBA というと、Xウインドウの何かのデスクトップで使って、結
局、大分重かったという話、ありませんでしたっけ?
In article <87vf5j9...@taito.co.jp>
takahide nojima <noj...@taito.co.jp> writes:
> どなたかWin環境のSunRPCを誰か作って公開してないかなーと思うこのごろです。
5年前には、存在していました。URL は、こんな感じでした。
http://www.dcs.qmul.ac.uk/~williams/nisgina-current/src/rpc110/oncrpc.htm
今は、存在しません。
検索してみたら、出てきました。これだ思います。
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> 新城@筑波大学情報です。こんにちは。
>
> CORBA というと、Xウインドウの何かのデスクトップで使って、結
> 局、大分重かったという話、ありませんでしたっけ?
CORBA+X環境だと、GNOMEでしょうか??
まあ、多くの人の使うような使い方ではデスクトップ用途にCORBAは
速度の面ではむいてなかったかも?ということなんでしょうね...
# なんでGNOMEのデスクトップ環境設計時においてCORBAが採用されたかの
#動機を自分も興味ありますので、今度調べてみようかなとは思ってます。
なお、今回はWin上で動作するライブラリの実行速度と呼び出しのパフォーマンスは
あまり要求されない用途なので、遅くてもも安心。
> In article <87vf5j9...@taito.co.jp>
> takahide nojima <noj...@taito.co.jp> writes:
> > どなたかWin環境のSunRPCを誰か作って公開してないかなーと思うこのごろです。
>
> 5年前には、存在していました。URL は、こんな感じでした。
>
> http://www.dcs.qmul.ac.uk/~williams/nisgina-current/src/rpc110/oncrpc.htm
>
> 今は、存在しません。
>
> 検索してみたら、出てきました。これだ思います。
>
> http://lost-contact.mit.edu/afs/net/project/afs32/su.se/src/win32/nisgina-1.0.2.0/src/rpc110/ONCRPC.HTM
>
情報ありがとうございます。でも見るとWin NT用途なんですね...ちょっと残念。
# MSプラットフォームはテクノロジの変遷激しくて、OSSのメンテが大変なのかなぁ...
In article <87acmua...@taito.co.jp>
takahide nojima <noj...@taito.co.jp> writes:
> CORBA+X環境だと、GNOMEでしょうか??
> # なんでGNOMEのデスクトップ環境設計時においてCORBAが採用されたかの
> #動機を自分も興味ありますので、今度調べてみようかなとは思ってます。
たしかに。私も気になります。「オブジェクト指向」入っていると
いうことで、採用したのかも。
> > http://lost-contact.mit.edu/afs/net/project/afs32/su.se/src/win32/nisgina-1.0.2.0/src/rpc110/ONCRPC.HTM
> >
> 情報ありがとうございます。でも見るとWin NT用途なんですね...ちょっと残念。
> # MSプラットフォームはテクノロジの変遷激しくて、OSSのメンテが大変なのかなぁ...
NT用というか、当時は、Windows 95 と Windows NT しかなくて、
だから NT 用と書いてあります。NT 用と書いてありますが、2000
では動きました。XP で動かない理由は、ちょっと思いつきません。
使っているのは、socket() とか write() とか、bcopy() とかその
程度なので、Windows のバージョンに依存している部分は少ないん
じゃないかなあ。
売り物がいいなら、いろいろあるみたいです。キーワードは、
oncrpc windowsくらい。どれがいいかは、わかりません。
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> > > http://lost-contact.mit.edu/afs/net/project/afs32/su.se/src/win32/nisgina-1.0.2.0/src/rpc110/ONCRPC.HTM
> > >
> > 情報ありがとうございます。でも見るとWin NT用途なんですね...ちょっと残念。
> > # MSプラットフォームはテクノロジの変遷激しくて、OSSのメンテが大変なのかなぁ...
>
> NT用というか、当時は、Windows 95 と Windows NT しかなくて、
> だから NT 用と書いてあります。NT 用と書いてありますが、2000
> では動きました。XP で動かない理由は、ちょっと思いつきません。
うーん、せっかく情報頂いて申し訳ないのですが、残念ながら、現在は上の
ホームページにあるダウンロード先の
ftp://ftp.gmd.de/gmd/I5.RS/SRPC110.ZIP
http://set.gmd.de/~mfg/SRPC110.ZIP
がリンク切れの模様。残念です。
> 売り物がいいなら、いろいろあるみたいです。キーワードは、
> oncrpc windowsくらい。どれがいいかは、わかりません。
結構MSプラットフォームって、売り物で固めなきゃいけない状況って
多いのですなぁ...残念。
In article <87mzqtb...@taito.co.jp>
takahide nojima <noj...@taito.co.jp> writes:
> > > > http://lost-contact.mit.edu/afs/net/project/afs32/su.se/src/win32/nisgina-1.0.2.0/src/rpc110/ONCRPC.HTM
> うーん、せっかく情報頂いて申し訳ないのですが、残念ながら、現在は上の
> ホームページにあるダウンロード先の
> がリンク切れの模様。残念です。
あ、わかりにくかったですね。上の HTML があるディレクトリは、
そのリンクの先を展開したものです。そこにCのソースがあります。
一発で持っていくなら、次のファイルがいいでしょう。
http://lost-contact.mit.edu/afs/net/project/afs32/su.se/src/win32/nisgina-1.0.2.0.tar.gz
私の手元にあるのは、zip だけれど。
展開すると、src/rpc110 というディレクトリができて、そこに
MAKE.BAT があります。それで、SunRPC の部分のライブラリは完結
しています。NISGINA は使わなくてもいいです。
In article <87mzqtb...@taito.co.jp> noj...@taito.co.jp writes:
> うーん、せっかく情報頂いて申し訳ないのですが、残念ながら、現在は上の
>ホームページにあるダウンロード先の
> ftp://ftp.gmd.de/gmd/I5.RS/SRPC110.ZIP
> http://set.gmd.de/~mfg/SRPC110.ZIP
>がリンク切れの模様。残念です。
「ダウンロード先」?
それは手元のパソコン等でしょう^_^;
「リンク先」であってかつ「ダウンロード元」であるURLのことを
ゴッチャにして「ダウンロード先」と言ってしまったんだと思いますが、
考えてみれば、結構「普及」してそうな表現ではあります。
どうなんでしょうね。
戸田 孝@滋賀県立琵琶湖博物館
to...@lbm.go.jp
情報ありがとうございました。
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> あ、わかりにくかったですね。上の HTML があるディレクトリは、
> そのリンクの先を展開したものです。そこにCのソースがあります。
> 一発で持っていくなら、次のファイルがいいでしょう。
>
> http://lost-contact.mit.edu/afs/net/project/afs32/su.se/src/win32/nisgina-1.0.2.0.tar.gz
>
> 私の手元にあるのは、zip だけれど。
>
> 展開すると、src/rpc110 というディレクトリができて、そこに
> MAKE.BAT があります。それで、SunRPC の部分のライブラリは完結
> しています。NISGINA は使わなくてもいいです。
ええ発見しました。うおおおっ、すばらしーっ、これでONC-RPCがWinでも使えるかも~
感動です。ありがとうございました。
Win*のNISクローンからONC-RPCを引くのは気がつきませんでした。感謝感激です。
>> CORBA+X環境だと、GNOMEでしょうか??
>> # なんでGNOMEのデスクトップ環境設計時においてCORBAが採用されたかの
>> #動機を自分も興味ありますので、今度調べてみようかなとは思ってます。
>
> たしかに。私も気になります。「オブジェクト指向」入っていると
> いうことで、採用したのかも。
X みたいに、1 端末中(xdm の「セッション」とか)に複数の
リモートプロセスが混在していると、その間の連携の実現ということでは
CORBA は自然な解なんじゃないでしょうか。
Sun も元々 CORBA を ONC-RPC の後継と位置付けていたと思います。
Spring でも使ってました。でもやめちゃったのは、やっぱ実装が重く
なるんですかね?
--
持田 修司 NETside Technologies Inc.
-- Equal Opportunity for All Good Architectures, NetBSD. --
In article <ul8acmrr5...@pine.yorie.netside.co.jp>
MOCHIDA Shuji <moc...@netside.co.jp> writes:
> 持田@NETside です。
> X みたいに、1 端末中(xdm の「セッション」とか)に複数の
> リモートプロセスが混在していると、その間の連携の実現ということでは
> CORBA は自然な解なんじゃないでしょうか。
「自然」ですか。もう少し「自然」の内容を教えてもらえますか。
私の感覚では、あんまり自然という感じはしません。X Window 生
でも、セレクション(コピー&ペースト)の所は、プロセス間通信
になっていますが、使っている方は「クリップボード」と思って使っ
ていると思っています。コピー元とコピー先で型のネゴシエーショ
ンが必要になるので、単にクリップボードよりは、RPC の方がいい
のは分かるのですが、自然という気はあんまりしません。
「コピー&ペースト」以上のことをしようとすると、RPC が出てく
るんでしょうけれど、あんまりパッとしたものが出てきません。
特に SunRPC ではダメで、CORBA ならいいという例です。
結局、Solaris は、ToolTalk とかで、SunRPC を使っているんですよね。
> Sun も元々 CORBA を ONC-RPC の後継と位置付けていたと思います。
> Spring でも使ってました。でもやめちゃったのは、やっぱ実装が重く
> なるんですかね?
Spring は、Sun Microsystems ですが、研究用の分散OSなので、必
ずしも後継という位置づけではないと思います。でも、Spring っ
て、そもそも CORBA なんか使ってましたっけ?
> 「自然」ですか。もう少し「自然」の内容を教えてもらえますか。
GNOME だと C++ なので、CORBA しかないかと。
# あれ? GNOME は C でしたっけ?
> ンが必要になるので、単にクリップボードよりは、RPC の方がいい
> のは分かるのですが、自然という気はあんまりしません。
まあ、そういうことだと思います。クリップボード以上の
連携機能を提供したいんだと私は思ってます。ウインドウシステムの
ツールキットだと、コマンドラインシェルのパイプ相当かそれ以上の
ものを提供すべき、でしょう。
> 特に SunRPC ではダメで、CORBA ならいいという例です。
SunRPC だとアプリケーション側の作業負荷が大きいですよね。
>> Sun も元々 CORBA を ONC-RPC の後継と位置付けていたと思います。
CORBA を進めるにあたって、Sun とどっかもう一社は静的呼び出し
(「呼び出し」は invoke だったと思う..)でいいと言っていて、
他の 2 社くらいが動的呼び出しを入れろ、ということで、それが通って
今のようになったと記憶しています。で、Sun が「静的呼び出しだけでいい」と
言っていた頃には、SunRPC の次の RPC という位置付けだったと思います。
> Spring は、Sun Microsystems ですが、研究用の分散OSなので、必
> ずしも後継という位置づけではないと思います。でも、Spring っ
> て、そもそも CORBA なんか使ってましたっけ?
Spring が「後継」と言ってるわけではありません。Spring は
マイクロカーネルのサービスインターフェース定義に IDL を
使っていたということです。
In article <ul8psvn...@pine.yorie.netside.co.jp>
MOCHIDA Shuji <moc...@netside.co.jp> writes:
> 持田@NETside です。
> > 「自然」ですか。もう少し「自然」の内容を教えてもらえますか。
> GNOME だと C++ なので、CORBA しかないかと。
そういう感覚か。CORBA も使ったことがないので、このあたりの感
覚は難しいです。
> > ンが必要になるので、単にクリップボードよりは、RPC の方がいい
> > のは分かるのですが、自然という気はあんまりしません。
> まあ、そういうことだと思います。クリップボード以上の
> 連携機能を提供したいんだと私は思ってます。ウインドウシステムの
> ツールキットだと、コマンドラインシェルのパイプ相当かそれ以上の
> ものを提供すべき、でしょう。
具体的に、「パイプ以上」というのは、どういうことでしょうか?
GNOME では、どうなっていますか?
> > 特に SunRPC ではダメで、CORBA ならいいという例です。
> SunRPC だとアプリケーション側の作業負荷が大きいですよね。
SunRPC は、使っていますが、アプリケーション側の負担が大きい
とは思ったことはありません。具体的にどの部分が大きいのですか?
> >> Sun も元々 CORBA を ONC-RPC の後継と位置付けていたと思います。
> CORBA を進めるにあたって、Sun とどっかもう一社は静的呼び出し
> (「呼び出し」は invoke だったと思う..)でいいと言っていて、
> 他の 2 社くらいが動的呼び出しを入れろ、ということで、それが通って
> 今のようになったと記憶しています。で、Sun が「静的呼び出しだけでいい」と
> 言っていた頃には、SunRPC の次の RPC という位置付けだったと思います。
CORBA も SunRPC も静的という意味ですか。
クライアントとサーバとの binding は、RPC ならだいたい動的だ
けど、そういう話ではないですよね。
> > Spring は、Sun Microsystems ですが、研究用の分散OSなので、必
> > ずしも後継という位置づけではないと思います。でも、Spring っ
> > て、そもそも CORBA なんか使ってましたっけ?
>
> Spring が「後継」と言ってるわけではありません。Spring は
> マイクロカーネルのサービスインターフェース定義に IDL を
> 使っていたということです。
CORBA の IDL を使っていたのですか?
IDL って、一般名詞的な使い方もする言葉なので、IDL が出てきて
も必ずしも CORBA を意味しません。SunRPC の IDL には名前がな
くて、時々困ります。rpcgen のソースとか、そんな言い方をした
りします。
CORBAもRPCもあまり詳しくないので、はずしてなければいいのですが。
In article <YAS.05Ma...@kirk.is.tsukuba.ac.jp>
Yasushi Shinjo wrote:
> 新城@筑波大学情報です。こんにちは。
> In article <ul8psvn...@pine.yorie.netside.co.jp>
> MOCHIDA Shuji <moc...@netside.co.jp> writes:
>> 持田@NETside です。
>> > 「自然」ですか。もう少し「自然」の内容を教えてもらえますか。
>> GNOME だと C++ なので、CORBA しかないかと。
GNOMEはC(gtk+)です。
KDEがC++(Qt)ですが、KDEはCORBAは使わずに独自実装したもの(DCOPやKParts)を使っています。
(当初はKDEでもCORBAを使おうとしていましたが、当時の実装(mico)が重すぎたためにあきらめました。)
>> まあ、そういうことだと思います。クリップボード以上の
>> 連携機能を提供したいんだと私は思ってます。ウインドウシステムの
>> ツールキットだと、コマンドラインシェルのパイプ相当かそれ以上の
>> ものを提供すべき、でしょう。
>
> 具体的に、「パイプ以上」というのは、どういうことでしょうか?
> GNOME では、どうなっていますか?
GNOMEは詳しくありませんが、GUIにおけるコンポーネントを欲しいためだと。
たとえばKDEの場合、DCOPは単なるメッセージのやり取りなのでここでは置いておくとして、
(DE(Desktop Environment)でのメッセージに関しては今後はD-BUSが無視できなくなるでしょうが)
KPartsを用いたコンポーネントで各アプリ/ユーザが好みのエディタコンポーネントを利用できます。
ex.
1. アプリがシステムにEditorコンポーネントのリストを要求
2. リストから優先順位(ユーザが変更可能)の高いコンポーネントを選んで埋め込みエディタとして利用。
こういうことをRPCで実現するのは手間がかかると思っています。
(RPCの一つ上のレイヤーを作ってしまえばいいだけでしょうが)
--
Che Che - Bye Bye
From: Takumi ASAKI <tak...@asaki.jp>
URL: http://asaki.jp/
takahide nojima <noj...@taito.co.jp> writes:
> ・IORのような機構が欲しかったから?
あー、すんません。IORのような機構が欲しいとかは間違いかも。SunRPCだって
問題ないですね。確かに。
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> 「コピー&ペースト」以上のことをしようとすると、RPC が出てく
> るんでしょうけれど、あんまりパッとしたものが出てきません。
> 特に SunRPC ではダメで、CORBA ならいいという例です。
>
> 結局、Solaris は、ToolTalk とかで、SunRPC を使っているんですよね。
GNOME関係のプログラムもしたことないですが、GONEにCORBA採用の理由って
・例外処理がSunRPCよりも今っぽかった?
・名前空間をいじりたかった?
・以下のようなカッチョイイことがしたかったから?
http://library.n0i.net/linux-unix/applications/x/gnome/faq/x703.html#BONOBO
・構想ではMSテクノロジ(Active-x/OLE2/DCOM/COM)の先を行くつもりだったから?
少なくとも同等のことが出来る以上の機構が欲しかった?
・IORのような機構が欲しかったから?
ぐらいなのかな...
> SunRPC は、使っていますが、アプリケーション側の負担が大きい
> とは思ったことはありません。具体的にどの部分が大きいのですか?
サーバー側で、ちょっと気のきいたことをしようと思うと、
rpcgen(1) が出力したコードに手を加えないといけなかった記憶があります。
> CORBA も SunRPC も静的という意味ですか。
> クライアントとサーバとの binding は、RPC ならだいたい動的だ
> けど、そういう話ではないですよね。
CORBA の動的起動というのは、サーバーを特定しないやつですよね。
>>> Spring は、Sun Microsystems ですが、研究用の分散OSなので、必
> CORBA の IDL を使っていたのですか?
そのはずです。
"Subcontract: A Flexible Base for Distributed Programming"
http://www.sunlabs.com/techrep/1993/abstract-13.html
3.1 The interface definition language
The unifying principle of Spring is that all the key interfaces are
defined in an interface definition language called IDL [OMG 1991].
This language is object-oriented and includes support for multiple
inheritance. It is purely concerned ...
"The Spring Virtual Memory System" の Appendices 等に実際の
定義らしきものが見えます。
http://www.sunlabs.com/techrep/1993/abstract-9.html
> も必ずしも CORBA を意味しません。SunRPC の IDL には名前がな
> くて、時々困ります。rpcgen のソースとか、そんな言い方をした
> りします。
Nutshell handbooks の RPC 本には RPCL、rpcgen(1) には
RPC Language (Remote Procedure Call Language) とありますね。
あまり特定の形式を示す雰囲気はしないかも。