From: senderista@... (Tobin Baker) Date: 2001-08-01T05:35:47+09:00 Subject: [ruby-talk:18914] Re: Dynamic ORBit bindings for Ruby MAP2303@mapletown.net wrote in message news:... > My interest goes to create CORBA binding to communicate with any other > CORBA ORB written in any languages. As you see, the current ORBit can talk > with only ORBit, so ruby-orbit is not a my main hobby. Yes, I'm not particularly interested in ORBit or GNOME (except for ORBit's speed). I actually have a project in the works which aims to be a universal Ruby binding for any Corba 2.3-compliant C++ ORB. I don't want to reveal the details just yet :-) I originally intended to use this approach with ORBit, but it wasn't compliant enough with the spec (and still isn't) to work. > >> Only the client-side bindings are > >> included in this release, but server-side bindings are being debugged > >> and should be ready in a few weeks. > > If your code is GPL compatible, how about my code? > It is not completed, but work. Well, the code has pretty much all been drafted already. I haven't had time to look at your code, but the way mine works is to create a server-side module for each interface Foo called "Foo_POA", and then the implementation class just includes this module. I've hooked append_features (as you can see in corba.rb) so that the implementation class's new method instantiates a native ORBit servant object (really a struct that can be cast to PortableServer_ServantBase) and registers it with ORBit. Is that roughly how your code works? > > >> Second, our approaches are > >> quite different. My bindings do not require any intermediate IDL > >> compilation step. After all, Ruby is a dynamic language, so why not > >> take advantage of that fact? With these bindings, if you want to use > >> a top-level module called "Foo" in some IDL file, you can just say > >> "require 'Foo'" at the top of your script, and the IDL file will be > >> located, parsed, and used to create Ruby types corresponding to all > >> IDL definitions in the file. The IDL file merely needs to be in a > > It is not so difficult because I write pure Ruby IDL compiler which have > dynamically compile and parse IDL code, but it is difficult that what > interface parsing dynamically is the best. > I used libIDL for parsing (and stole almost all the parsing code from CORBA::ORBit/orbit-python) > >> I have tried to document the IDL-Ruby mapping I have used as > >> thoroughly as possible in the README. Unfortunately, there hasn't > >> been enough English-language documentation available for ruby-orbit or > >> rinn to ensure compatibility with Dai's mapping. > > I'm sorry but I'm not good at English... > That's OK; I'm not good at Japanese :-) But if your documentation of the mapping is thorough enough to warrant it, I would hugely appreciate it if someone would volunteer to translate it. > >> But I think that as > >> people start to use both our bindings, we'll eventually be able to > >> come to a consensus on a standard IDL-Ruby mapping. > > Me too. > My CORBA Ruby project include to define CORBA-Ruby standard specification. > I've already gotten some email feedback (from someone who knows Ruby a lot better than I do) that indicates I already made some basic design mistakes in the mapping. That's why I want to see your mapping. > The main problems I think are: > > - fixed point > It is better we use fixed point library independent with CORBA-Ruby. I agree, a standard fixed-point library for Ruby should be developed independently of our CORBA projects, and it should be generally useable (and maybe eventually integrated into the standard library). > - TypeCode and Any > I've not read CORBA specification about it. TypeCode support is needed mainly for Any support, since the TypeCode contained in an Any contains all the type information for the enclosed value. I may make the entire TypeCode interface available from Ruby in the next release. It would be pretty trivial to implement. > - Helper and Holder. > Are they need? > I think helper is usable, but holder is not. Why would helper classes be necessary in Ruby? Holder classes could be used for out and inout arguments, although I take a different approach in my mapping (which I discussed here awhile back). > - code set conversion. > I hear the next Ruby support multilingualization(M17N). > Altough I don't know about it, I wait it. I agree, I'll wait for internationalization support from Ruby before trying to implement wchar and wstring.