«

Hello
I would like to create an API for a piece of Python code. The API is for use
by non Python code.
It should support interaction in both directions, both accessing functions
on the API and the ability for the API to raise events on its client.
What is the best way to do that?
I though of doing it as a python COM server but I am not familiar with COM
and I saw that implementing a COM server with events in python is not
trivial for me.
Is there a better (or simpler) solution?
What are the common ways for doing that?

Any answer would be highly appreciated.
Regards
Gary

While not sure of the behavior you are trying to achieve, XML-RPC comes
to mind. But it's based on HTTP protocol in which the client puts
request to the server which has to respond. The server cannot initiate
interactions.
XML-RPC is both widely avalaible, and very easy to implement.

NOTE: in order for the server to raise events in the client, the client
needs only raise periodically a *need-anything-from-me* type of request
which permits the server to return its request in response to the
client. Naturally this solution makes superfluous calls takes some
bandwidth, so it might not be appropriate in every circumstance.

Gary Kshepitzki wrote:
> I would like to create an API for a piece of Python code. The API is for use
> by non Python code.
> It should support interaction in both directions, both accessing functions
> on the API and the ability for the API to raise events on its client.
> What is the best way to do that?

One technology that I used many years ago with Python, and which should
still do the job is CORBA - at that time ILU, but I suppose the various
other ORBs should also be as capable; certainly, ILU permitted
callbacks from the server into the client. These days, you might want
to look at omniORB, Fnorb and ORBit.

Paul

Thanks
Its an interesting solution but I need a more closely coupled solution,
with real time events, so the communication really has to be 2 ways, and not
by polling.
Thanks for putting the time and though.
Gary


<> wrote in message
news: oups.com...
> While not sure of the behavior you are trying to achieve, XML-RPC comes
> to mind. But it's based on HTTP protocol in which the client puts
> request to the server which has to respond. The server cannot initiate
> interactions.
> XML-RPC is both widely avalaible, and very easy to implement.
>
> NOTE: in order for the server to raise events in the client, the client
> needs only raise periodically a *need-anything-from-me* type of request
> which permits the server to return its request in response to the
> client. Naturally this solution makes superfluous calls takes some
> bandwidth, so it might not be appropriate in every circumstance.
>

On 16 Nov 2005 06:18:05 -0800, Paul Boddie <> wrote:

> Gary Kshepitzki wrote:
>> I would like to create an API for a piece of Python code. The API is for use
>> by non Python code.
>> It should support interaction in both directions, both accessing functions
>> on the API and the ability for the API to raise events on its client.
>> What is the best way to do that?
>
> One technology that I used many years ago with Python, and which should
> still do the job is CORBA - at that time ILU, but I suppose the various
> other ORBs should also be as capable; certainly, ILU permitted
> callbacks from the server into the client. These days, you might want
> to look at omniORB, Fnorb and ORBit.
>
> Paul

I never saw any way to create callbacks from server to client with CORBA. How would you describe such a callback in the IDL file?

TIA
--
python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17;8(%,5.Z65\'*9--56l7+-'])"

Gary Kshepitzki wrote:
> Hello
> I would like to create an API for a piece of Python code. The API is for use
> by non Python code.
> It should support interaction in both directions, both accessing functions
> on the API and the ability for the API to raise events on its client.
> What is the best way to do that?
> I though of doing it as a python COM server but I am not familiar with COM
> and I saw that implementing a COM server with events in python is not
> trivial for me.
> Is there a better (or simpler) solution?
> What are the common ways for doing that?
>
> Any answer would be highly appreciated.
> Regards
> Gary
>
>

You could try Elmer:
http://elmer.sourceforge.net/index.html

I'm sure you could create a callable library (.so, .dll, etc) with it.

-Don

"Eric Brunel" <> writes:
> On 16 Nov 2005 06:18:05 -0800, Paul Boddie <> wrote:
>> One technology that I used many years ago with Python, and which should
>> still do the job is CORBA - at that time ILU, but I suppose the various
>> other ORBs should also be as capable; certainly, ILU permitted
>> callbacks from the server into the client. These days, you might want
>> to look at omniORB, Fnorb and ORBit.
> I never saw any way to create callbacks from server to client with CORBA. How would you describe such a callback in the IDL file?

It's OO, not functional. You pass an object to the server, and the
server invokes methods on that object. In the IDL, you use the
interface name as a type. I.e.:

interface Window {
...
}

and in another interface:
WindowList FindWindows(in Window name) ;

And, FWIW, Fnorb hasn't been maintained for a while. It requires
patching to run on recent versions of Python.

<mike
--
Mike Meyer <> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more
information.

On Wed, 16 Nov 2005 15:43:33 -0500, Mike Meyer <> wrote:

> "Eric Brunel" <> writes:
>> On 16 Nov 2005 06:18:05 -0800, Paul Boddie <> wrote:
>>> One technology that I used many years ago with Python, and which should
>>> still do the job is CORBA - at that time ILU, but I suppose the various
>>> other ORBs should also be as capable; certainly, ILU permitted
>>> callbacks from the server into the client. These days, you might want
>>> to look at omniORB, Fnorb and ORBit.
>> I never saw any way to create callbacks from server to client with CORBA. How would you describe such a callback in the IDL file?
>
> It's OO, not functional. You pass an object to the server, and the
> server invokes methods on that object. In the IDL, you use the
> interface name as a type. I.e.:
>
> interface Window {
> ...
> }
> and in another interface:
> WindowList FindWindows(in Window name) ;

This is slowly drifting OT, but aren't the interfaces in the IDL implemented on the server, and not on the client? So passing an "interface instance" to a method will just make the server call itself, won't it? Or you have to turn your client into a server, which makes things a lot more complicated.

> And, FWIW, Fnorb hasn't been maintained for a while. It requires
> patching to run on recent versions of Python.

Back on-topic: it seems to run fine with Python 2.1. I don't know about later versions.
--
python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17;8(%,5.Z65\'*9--56l7+-'])"

In article <437b6d1a$>,
dwelch <> wrote:
>Gary Kshepitzki wrote:
>> Hello
>> I would like to create an API for a piece of Python code. The API is for use
>> by non Python code.
>> It should support interaction in both directions, both accessing functions
>> on the API and the ability for the API to raise events on its client.
>> What is the best way to do that?
>> I though of doing it as a python COM server but I am not familiar with COM
>> and I saw that implementing a COM server with events in python is not
>> trivial for me.
>> Is there a better (or simpler) solution?
>> What are the common ways for doing that?
.
.
.
>You could try Elmer:
>http://elmer.sourceforge.net/index.html
>
>I'm sure you could create a callable library (.so, .dll, etc) with it.
.
.
.
You guys work too hard.

My reaction is this: Mr. Kshepitzki asks for an IPC choice,
says that COM looks like a bit too much, and respondents
start by loading him with even *heavier* technical alterna-
tives, such as CORBA. Whew! My recommendation: a simple
project-specific line-oriented bilateral TCP/IP implementa-
tion. Both server and client can listen for incoming
messages. My guess is that the *... Cookbook* has a sketch
of this in a few dozen lines. Perhaps after I've searched
it, I'll follow-up with a specific reference.

Cameron Laird wrote:
> You guys work too hard.

I beg to differ.

> My reaction is this: Mr. Kshepitzki asks for an IPC choice,
> says that COM looks like a bit too much, and respondents
> start by loading him with even *heavier* technical alternatives, such as CORBA.

Well, my relatively limited experience with COM-related technologies
suggests that it can be "a bit too much" in terms of the administrative
hassle of declaring interfaces, registering components, and so on.
However, if CORBA-related technologies from the late 1990s could manage
to work so well with Python that one didn't even need to manually
generate the various stubs to access remote services, one would hope
that such practices haven't been abandoned in the CORBA systems
available for Python today.

Looking at some of the omniORB tutorials gives the impression that
there's a certain number of magic utterances that need to be included
in any given program (either client or server) in order to get the
underlying mechanisms up and running, but I think that's to be expected
for any kind of distributed system. My point was that in adopting
something like CORBA, you might need to tolerate a certain amount of
boilerplate code but can then expect various tricky aspects of the
communications mechanisms to have been thought through on your behalf,
meaning that callbacks and other things just work. Rolling your own
solution, on the other hand, can end in a long road discovering what
those CORBA people were doing for all those years.

I suppose if CORBA is too heavy, there's always PYRO. I can't comment
on whether PYRO will be able to do what was requested, however.

Paul