[omniORB-dev] Implementation Repository

[James Waller]

> Each time a distinct client uses one of the indirect
> references, it hits 
> the ImR first.  I would think this would happen as
> much or more often 
> than generation of the references in the first
> place, and so you may be 
> avoiding a small percentage of the load the ImR will
> face.

[snip]

Well, I'm starting to come around to the idea; it
imposes less restrictions from an ORB portability
standpoint and it doesn't tie the ImR to the POA, i.e.
it would work with old BOA-based servers. That's
something I started to think about recently. Plus it
would allow me to shave a whole lot of code off what
I've got now!

> But hey, if the interceptor is already written to do
> the job, I won't 
> argue.  One of my goals is for the ImR to work with
> C++ and Python 
> servers.  Can the interceptor be installed in a
> Python server?
> 
> Kendall
>

You got me there. My current implementation does not
support Python, that would probably require a
Python-based implementation of the server helper
library. That's assuming the interceptor stuff is
still available. I've dabbled a little bit with Python
but I'm not familiar with omniORB's Python API. It's
something that I intended to do later; I wanted to get
something working with C++ to start with.

By switching my design to require explicit publishing
of IORs to the ImR, this would remove the need for the
interceptor stuff from the server side hence trimming
down the server helper library and making it easier to
port to other languages. I need to do some serious
thinking about all this.

Cheers,
James

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com