MAP2303 / mapletown.net wrote in message news:<wS4a7.21165$WD1.1265201 / e420r-atl2.usenetserver.com>...
> in <dbbeaaa3.0107311226.54de53aa / posting.google.com>
> senderista / hotmail.com wrote:
> 
> >> MAP2303 / mapletown.net wrote in message news:<g%r97.6906$WD1.415204 / e420r-atl2.usenetserver.com>...
>  
> >> 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.

That's pretty much how my code works (I too only use the
PortableServer_ServantBase epv), except that I have the client include
a "skeleton module" rather than subclass a skeleton class.  I thought
this would give clients more flexibility if they already wanted to
subclass something else.