[omniORB] Implementation Repository

[James Waller]

No, it shouldn't be a problem changing the file suffixes. I'll post you
a modified version later on with this corrected. I didn't start looking
at the omniORB sources until later on, when I noticed the difference.

Server-side python support should be relatively simple. All you need to
do is implement a Python version of the omniImR::Server interface, using
the C++ one (include/ServerProxyPOA.h) as a road-map, and create an
instance of it within your server. There are three remote operations in
the interface, here is a run-down of them:

deactivateNotify(): Called by the ImR when it wants the server to
deactivate itself. The standard implementation shuts down the ORB to
break out of the event processing loop. It is intended to be overridden
to perform any extra application-specific clean-up steps.

sendPing(): Called by the ImR when it wants to ping the server. The
implementation of this function should simply call the recvPing()
operation of the passed object reference (which is the ImR-side
implementation of the omniImR::Server interface) with the numeric ping
ID which was passed in.

recvPing(): Called by the remote end when bouncing back a ping; this is
currently used only by the ImR-side omniImR::Server implementation.

A server is also passed a command-line, -ImRInstanceID, with a value
corresponding to the server's process ID; the server needs to take this
value from the command string and use it in a call to
omniImR::Repository::serverReady().

Once this interface has been implemented you should have little trouble
writing Python-based servers for omniImR.

Cheers,
James


Thomas Lockhart wrote:
 > OK, I've gotten the tarball from the mailing list posting (but would be
 > happy to post it also so folks don't have to figure out how to peel it
 > out of the text message).
 >
 > I notice that the sources are labeled as ".c++" rather than the ".cc" as
 > used in omniORB and as commonly used in other packages. Would you be
 > opposed to having these files relabeled with that convention?
 >
 > I'm not sure if there was a decision on whether this is a standalone
 > package or something inside the omniORB tree (and later the omniORBpy
 > tree too). If it is standalone, I can work on autoconf support, which
 > should be pretty easy with enough borrowing from the omniORB
 > infrastructure. If it is merged, then most of the make system can just
 > be adopted from an existing example.
 >
 > I'm curious to see what it will take to get server-side python support.
 >
 >                    - Tom
 >
 >
 >