[ruby-talk:18914] Re: Dynamic ORBit bindings for Ruby

[e-mail] wrote in message news:<g%r97.6906$[e-mail]>...
>   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.