How to write an API for a Python application?

G

Gary Kshepitzki

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
 
J

jmdeschamps

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.
 
P

Paul Boddie

Gary said:
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
 
G

Gary Kshepitzki

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
 
E

Eric Brunel

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
 
D

dwelch

Gary said:
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
 
M

Mike Meyer

Eric Brunel said:
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
 
E

Eric Brunel

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.
 
C

Cameron Laird

.
.
.
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.
 
P

Paul Boddie

Cameron said:
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
 
M

Mike Meyer

Eric Brunel said:
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.

Yes, your client turns into a server. That's pretty much required for
callbacks to work, no matter what technology you use. While the
details are a lot more complicated than being a simple client, you get
to ignore a lot of them - like how clients find you - and a lot of the
rest are taken care of by the ORB, which you have to have to be a
CORBA client.

What you pass isn't an "interface instance", it's a locator for an
object that implements the interface. So you can pass an instance on
the server if you really want to, but you can also pass one for the
client.

<mike
 
C

Cameron Laird

.
.
.
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
.
.
.
Indeed, Paul: those who scorn CORBA often *do* re-create it,
poorly.

I still don't think it's the right answer for Mr. Kshepitzki.
Pyro might be perfect. My own instinct is to start even more
primitively, with a minimal asynchat client and server. I've
looked through the *Cookbook*, and see that it doesn't have
what I want. Maybe it's time Phaseit donate one of the
little models we use ...
 
M

Mike Meyer

.
Indeed, Paul: those who scorn CORBA often *do* re-create it,
poorly.

I still don't think it's the right answer for Mr. Kshepitzki.
Pyro might be perfect. My own instinct is to start even more
primitively, with a minimal asynchat client and server. I've
looked through the *Cookbook*, and see that it doesn't have
what I want. Maybe it's time Phaseit donate one of the
little models we use ...

CORBA includes an awful lot of things that probably aren't needed for
Mr. Kshepitzki's application. If the choice comes down to CORBA or
rolling your own at the socket level, I'll take CORBA. But there's
lots of room for other solutions in between those two. I've played
with the idea of a simple, single-connection protocol that would do
what he wanted, without all the excess. If someone had something
similar to that already written, it'd be great.

<mike
 
D

Duncan Grisby

Indeed, Paul: those who scorn CORBA often *do* re-create it,
poorly.

I still don't think it's the right answer for Mr. Kshepitzki.
Pyro might be perfect. My own instinct is to start even more
primitively, with a minimal asynchat client and server. I've
looked through the *Cookbook*, and see that it doesn't have
what I want. Maybe it's time Phaseit donate one of the
little models we use ... [/QUOTE]

Pyro is definitely of no use to the original poster. He specifically
wants to access his Python server from languages other than Python.

To me, the situation sounds complex enough, especially with the need
for callbacks, that CORBA is an ideal solution. At the expense of a
small amount of boilerplate code, all the communication issues are
handled for you. In this day and age, why would you want to write code
that deals with sockets apart from the most specialist situations?

Cheers,

Duncan.
 
P

Piet van Oostrum

Duncan Grisby said:
DG> To me, the situation sounds complex enough, especially with the need
DG> for callbacks, that CORBA is an ideal solution. At the expense of a
DG> small amount of boilerplate code, all the communication issues are
DG> handled for you. In this day and age, why would you want to write code
DG> that deals with sockets apart from the most specialist situations?

A more lightweight solution might be Ice. <http://www.zeroc.com/ice.html>
It is architecturally similar to Corba, but with less overhead. And
supports different programming languages and platforms.
But if your application is to be distributed on a non-GPL license you have
to pay.
That said, I think there is nothing wrong with using Corba for this kind of
thing. It has an additional advantage that it is a widely accepted standard.
 
D

Duncan Grisby

Piet van Oostrum said:
A more lightweight solution might be Ice. <http://www.zeroc.com/ice.html>
It is architecturally similar to Corba, but with less overhead.

More lightweight and less overhead in what sense? The performance
measurements I've seen show that Ice is significantly slower than many
CORBA implementations. If you mean more lightweight in terms of ease
of use, I don't see how. I quite agree that it's more lightweight in
terms of size of specification and difficulty for the ORB implementor,
but that's largely irrelevant to the users of the technology.

Cheers,

Duncan.
 
P

Piet van Oostrum

Duncan Grisby said:
DG> More lightweight and less overhead in what sense? The performance
DG> measurements I've seen show that Ice is significantly slower than many
DG> CORBA implementations. If you mean more lightweight in terms of ease
DG> of use, I don't see how. I quite agree that it's more lightweight in
DG> terms of size of specification and difficulty for the ORB implementor,
DG> but that's largely irrelevant to the users of the technology.

On http://www.zeroc.com/performance/ they compare it with TAO and it seems
to be faster. It looks also a bit simpler. I don't have experience with Ice
myself but a colleague of mine experimented with it and was enthousiastic.

It could well be that it is comparable in speed to omniORB, which is my
favorite platform for Corba on Python, or maybe even slower. Do you have
benchmark results about that?

But as I also said there is nothing wrong with using Corba, and the
advantage is that it is an established standard.
 
C

Cameron Laird

.
.
.
Pyro might be perfect. My own instinct is to start even more
primitively, with a minimal asynchat client and server. I've
looked through the *Cookbook*, and see that it doesn't have
what I want. Maybe it's time Phaseit donate one of the
little models we use ...

Ah-ha! See Example 19-7, on page 447 of *Python in a Nutshell*:
under two dozen lines that provide an echo server which correctly
handles multiple concurrent clients.

But that's also about as much as I've found publicly in that
direction. The original questioner wanted, or thought he wanted,
an object-capable protocol, so he could invoke methods remotely;
for that, I return to Paul Boddie's correct observation that
folks can use CORBA, or imitate CORBA badly (as much of this
season's "SOA" does). What I don't see, though, is a nice client-
server pair that are minimal, and exhibit *symmetric* event-oriented
performance and scalability. Some people mistakenly regard this
"peering" architecture as a dark secret. I think I'll write a model
in under fifty lines of Python this week ...
 
A

Alex Martelli

Cameron Laird said:
.
.
.

Ah-ha! See Example 19-7, on page 447 of *Python in a Nutshell*:
under two dozen lines that provide an echo server which correctly
handles multiple concurrent clients.

Note also that you can freely download all of the code in my book as
http://examples.oreilly.com/pythonian/pythonian-examples.zip (it's just
36 KB). In that same chapter you will find several implementations of
mutually compatible clients and servers for that same echo-oid
"protocol" (as well as one incompatible one using UDP -- all the others
use TCP). I hope they can be useful to anybody wanting to kludge
together some simple TCP/IP thingy (though, for the problem being
discussed in this thread, I'd rather recommend Corba;-).


Alex
 
D

Duncan Grisby

Piet van Oostrum said:
On http://www.zeroc.com/performance/ they compare it with TAO and it seems
to be faster. It looks also a bit simpler. I don't have experience with Ice
myself but a colleague of mine experimented with it and was enthousiastic.

It could well be that it is comparable in speed to omniORB, which is my
favorite platform for Corba on Python, or maybe even slower. Do you have
benchmark results about that?

I've not done any benchmarks for Python (yet), but I've just posted
some results to comp.object.corba that show omniORB is a lot faster
than Ice for many things.

Cheers,

Duncan.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top