I think you have some good points.  Such a framework as you describe
would make it more straightforward to create Ruby bindings for a given
ORB (since you would be implementing a single API).  And these
modules/classes/methods could be dynamically eval'ed if necessary (as
in my approach) instead of actual code being generated.  A single Ruby
module could parse an IDL file and either emit Ruby code or
dynamically create the corresponding modules/classes/methods.  If the
ORB being implemented is a shared library, we could even specify the
ORB at runtime, something like:

require 'CORBA'  (IDL parsing and code generation/evaluation module)
require 'ORBit'  (implementation module used by CORBA module)
require 'Foo'  (module in IDL file or stub/skeleton code)

This would be way ahead of anything I am aware of that's available in
Perl or Python!

On a related note, I've been thinking for a while about (but haven't
had any time to work on) an idea that would take portability still
further.  It would achieve similar portability to the above approach,
but would actually extend it to proprietary ORB's for which the
internal API is unavailable.  Basically it uses the DII, TypeCode, and
DynAny interfaces to construct a universal CORBA client (and possibly
a limited CORBA server using the DSI).  All marshaling/unmarshaling,
method dispatch, and other details which are traditionally accessible
only through the ORB's internal API can, at least theoretically, be
implemented purely in terms of these standard CORBA interfaces.  I
originally intended to implement my ORBit bindings in this way, but
ORBit wasn't (and still isn't) sufficiently compliant for it to work. 
Any CORBA 2.3-compliant ORB, however, should work.  I plan to
implement this in C++, at least initially, since C++ ORB's are far
more prevalent (and more compliant) than C ORB's.  I was thinking of
starting with omniORB.  The way I think our projects could fit
together is something like this.  We first define the Ruby-IDL
mapping.  Then we (or you) define the standard Ruby client/server
interface.  Then we (or I) implement this interface purely in terms of
the IDL C++ mapping.  Now we have an API which can have either an
ORB-specific implementation (like your ORBit wrapper) for efficiency,
or a portable implementation (possibly at some loss of efficiency,
depending on how well the DynAny and DII interfaces are implemented). 
I think this combination would put Ruby way ahead of other scripting
languages.  What are your thoughts (and anyone else's)?

Daisuke KANDA <MAP2303 / mapletown.net> wrote in message news:<20010824.173103.28781370.dai / iij-mc.co.jp>...
> > Sorry, I haven't checked the newsgroups for awhile.  I'm extremely
> > busy right now and will not be able to work on any CORBA stuff for at
> > least a few weeks.  Did you get the tarball to compile and work?
> 
>   Hi Tobin, you need not mind it.
>   I suspect I'll be busy incoming a few month because of as employment and because I'll
> join new small opensource project.
>   (ah why are there many and many issues which urge me hack? ;-) )
> 
> 
>   I've gotten your code(thanks for your help about downloading) and roughly read source code,
> but have not compile or run it.
> 
> 
> > I agree that common classes like system exceptions, a union type, an
> > any type, a fixed-point type and (maybe) enums are needed.
> 
>   Sounds good.
>   Although these mey not be so big code, shall we open CVS directory for commiting
> our fragment code which will be created in our intermittent free time?
>   (At sourceforge, I like.)
> 
> 
> >  But I
> > guess I don't see the need for common stub/skeleton interfaces like
> > Java.  The Java portable stub/skeleton interface is important because
> > it guarantees the portability of client code.
>  
> >  But I'm not convinced
> > that Ruby clients should be using stubs/skeletons in the first place. 
> 
>   I also agree that stub/skeletons need not be seen from developer.
> 
>   I don't claim that all developer of client or server should generate stub/skeleton
> from IDL before running his application.
>   We should supply API which dynamically compile IDL and generate stub/skeleton then load
> it, such as your new ``require'' method.
>   (But I don't understand the need to replace standard require method)
> 
>   I claim to standardize an interface between ORB and client/server code.
>   For example, how to stub marshall and send request to ORB.
> 
>     //IDL
>     short foo(in short arg);
> 
>     # stub
>     def foo(arg)
>       buf = _request()        # how to get ORB's message buffer to send?
>       buf.write_short(arg)    # is it better for buffer using the write_ method?
>       ret = buf.invoke("foo") # when and how stub pass method name to ORB?
>       return [ret]
>     end
> 
>   other stub code is possible.
> 
>     # stub
>     def foo(arg)
>       buf = _request("foo")
>       buf.puts({"short" => arg})
>       ret = buf.invoke()
>       return [ret]
>     end
>   
>   It is no benefit that there are many different interface but do substantially same work.
> 
> 
>   Separating stub/skeleton generator and ORB make it possible:
>     - for client/server developer to choice stub/skeleton generator and ORB independently.
>     - for ORB implementor to separate these code and keep it simple.
>     - for ORB other than CORBA easy to connect our platform.
>     - after all, these scheme may be need for DII or DSI.
> 
> 
>   And its defect I think are:
>     - All ORB implementors need a bit more work. But it is not so hard.
>       He or she need to create only simple wrapper for his/her ORB implementation.
>       (My ORBit wrapper use its style.)
>     - Any developer who interested in how ORB work can see stub/skeleton code.
>       I think it is rather a good environment than environment of which developer cannot
>      get internal information.