Hello Tobin. >> I've just finished the alpha release of >> my own ORBit bindings for Ruby. First of all, I'm glad to see other people interested in Ruby ORBit. >> Why two ORBit bindings, you ask? Well, first, when I began this >> project, Dai had stopped work on ruby-orbit for over a year, and it >> was not clear when he was going to resume. # It is not so rare FOR ME to stop my programs over years(^^; 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. But why do I revive it? This reason is there is a person who need ruby-orbit to support more ORBit functions and I've not known other people who try to tackle to hack ruby-orbit. >> 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. >> The DII is >> not supported since it is really unnecessary given the dynamic nature >> of both Ruby and these bindings. I think so. (and same about DSI.) >> 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 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... >> 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. The main problems I think are: - fixed point It is better we use fixed point library independent with CORBA-Ruby. - TypeCode and Any I've not read CORBA specification about it. - Helper and Holder. Are they need? I think helper is usable, but holder is not. - code set conversion. I hear the next Ruby support multilingualization(M17N). Altough I don't know about it, I wait it.