From: MAP2303@... Date: 2001-08-02T08:23:29+09:00 Subject: [ruby-talk:18998] Re: Dynamic ORBit bindings for Ruby in senderista@hotmail.com wrote: >> MAP2303@mapletown.net wrote in message news:... >> 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? My code is more internally I think. When ORBit dispatch method invocation, it traces following steps. 1. get ClassInfo structure from Servant structure. 2. call relay_call function which is ClassInfo hold. 3. relay_call, which genereted by IDL compiler, checks client specify a valid method name and returns pointer of skeleton function. 4. ORBit calls the skeleton funcion. 5. skeleton function, which is also genereted by IDL compiler, unmarshall request and call user defined function. My ruby-orbit supply Servant class which user should extends for his server class. Servant class have ORBit's Servant structure and initialized its classinfo as relay_call point to my rorbit_relay_call(). this function invoke _relay_call() method. Servant class have basic _relay_call() method. It checks given method name is respoind_to? and return its name. _relay_call() returns always skeleton wrapper funcion. This wrapper invokes ruby method by name which given client. so my code is not use epv vector per interface.