How to write an API for a Python application?

[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

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

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

[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
<jm*********@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr 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.

[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
<jm*********@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr 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.

[Paul Boddie]

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

[Paul Boddie]

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

[Eric Brunel]

On 16 Nov 2005 06:18:05 -0800, Paul Boddie <pa**@boddie.org.uk> 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+-'])"

[Eric Brunel]

On 16 Nov 2005 06:18:05 -0800, Paul Boddie <pa**@boddie.org.uk> 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+-'])"

[dwelch]

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

[dwelch]

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

[Mike Meyer]

"Eric Brunel" <er*********@despammed.com> writes:

On 16 Nov 2005 06:18:05 -0800, Paul Boddie <pa**@boddie.org.uk> 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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more
information.

[Mike Meyer]

"Eric Brunel" <er*********@despammed.com> writes:

On 16 Nov 2005 06:18:05 -0800, Paul Boddie <pa**@boddie.org.uk> 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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more
information.

[Eric Brunel]

On Wed, 16 Nov 2005 15:43:33 -0500, Mike Meyer <mw*@mired.org> wrote:

"Eric Brunel" <er*********@despammed.com> writes:

On 16 Nov 2005 06:18:05 -0800, Paul Boddie <pa**@boddie.org.uk> 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+-'])"

[Eric Brunel]

On Wed, 16 Nov 2005 15:43:33 -0500, Mike Meyer <mw*@mired.org> wrote:

"Eric Brunel" <er*********@despammed.com> writes:

On 16 Nov 2005 06:18:05 -0800, Paul Boddie <pa**@boddie.org.uk> 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+-'])"

[Cameron Laird]

In article <43********@usenet01.boi.hp.com>,
dwelch <do**********@hp.com> 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?

[Cameron Laird]

In article <43********@usenet01.boi.hp.com>,
dwelch <do**********@hp.com> 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?

[Paul Boddie]

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

[Paul Boddie]

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

[Mike Meyer]

"Eric Brunel" <er*********@despammed.com> writes:

On Wed, 16 Nov 2005 15:43:33 -0500, Mike Meyer <mw*@mired.org> wrote:

"Eric Brunel" <er*********@despammed.com> writes:

On 16 Nov 2005 06:18:05 -0800, Paul Boddie <pa**@boddie.org.uk> 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.

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

"Eric Brunel" <er*********@despammed.com> writes:

On Wed, 16 Nov 2005 15:43:33 -0500, Mike Meyer <mw*@mired.org> wrote:

"Eric Brunel" <er*********@despammed.com> writes:

On 16 Nov 2005 06:18:05 -0800, Paul Boddie <pa**@boddie.org.uk> 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.

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Cameron Laird]

In article <11********************@f14g2000cwb.googlegroups.c om>,
Paul Boddie <pa**@boddie.org.uk> wrote:

[Cameron Laird]

In article <11********************@f14g2000cwb.googlegroups.c om>,
Paul Boddie <pa**@boddie.org.uk> wrote:

[Mike Meyer]

cl****@lairds.us (Cameron Laird) writes:

In article <11********************@f14g2000cwb.googlegroups.c om>,
Paul Boddie <pa**@boddie.org.uk> wrote:
.

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

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

cl****@lairds.us (Cameron Laird) writes:

In article <11********************@f14g2000cwb.googlegroups.c om>,
Paul Boddie <pa**@boddie.org.uk> wrote:
.

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

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Duncan Grisby]

In article <cf************@lairds.us>, Cameron Laird <cl****@lairds.us> wrote:

[...]

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

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.

--
-- Duncan Grisby --
-- du****@grisby.org --
-- http://www.grisby.org --

[Duncan Grisby]

In article <cf************@lairds.us>, Cameron Laird <cl****@lairds.us> wrote:

[...]

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

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.

--
-- Duncan Grisby --
-- du****@grisby.org --
-- http://www.grisby.org --

[Piet van Oostrum]

>>>>> Duncan Grisby <du*********@grisby.org> (DG) wrote:

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.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org

[Piet van Oostrum]

>>>>> Duncan Grisby <du*********@grisby.org> (DG) wrote:

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.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org

[Duncan Grisby]

In article <m2************@ordesa.lan>,
Piet van Oostrum <pi**@cs.uu.nl> wrote:

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.

--
-- Duncan Grisby --
-- du****@grisby.org --
-- http://www.grisby.org --

[Duncan Grisby]

In article <m2************@ordesa.lan>,
Piet van Oostrum <pi**@cs.uu.nl> wrote:

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.

--
-- Duncan Grisby --
-- du****@grisby.org --
-- http://www.grisby.org --

[Piet van Oostrum]

>>>>> Duncan Grisby <du*********@grisby.org> (DG) wrote:

DG> In article <m2************@ordesa.lan>,
DG> Piet van Oostrum <pi**@cs.uu.nl> wrote:

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

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.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org

[Piet van Oostrum]

>>>>> Duncan Grisby <du*********@grisby.org> (DG) wrote:

DG> In article <m2************@ordesa.lan>,
DG> Piet van Oostrum <pi**@cs.uu.nl> wrote:

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

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.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org

[Cameron Laird]

In article <cf************@lairds.us>, I mumbled:

[Cameron Laird]

In article <cf************@lairds.us>, I mumbled:

[Alex Martelli]

Cameron Laird <cl****@lairds.us> wrote:

In article <cf************@lairds.us>, I mumbled:
.
.
.

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.

Note also that you can freely download all of the code in my book as
http://examples.oreilly.com/pythonia...n-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

[Alex Martelli]

Cameron Laird <cl****@lairds.us> wrote:

In article <cf************@lairds.us>, I mumbled:
.
.
.

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.

Note also that you can freely download all of the code in my book as
http://examples.oreilly.com/pythonia...n-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

[Duncan Grisby]

In article <m2************@ordesa.lan>,
Piet van Oostrum <pi**@cs.uu.nl> wrote:

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.

--
-- Duncan Grisby --
-- du****@grisby.org --
-- http://www.grisby.org --

[Piet van Oostrum]

>>>>> Duncan Grisby <du*********@grisby.org> (DG) wrote:

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

Very n ice (that was an accident, but I decided to let it stay).
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org

[Cameron Laird]

In article <1h*************************@mail.comcast.net>,
Alex Martelli <al***@mail.comcast.net> wrote:

[Alex Martelli]

Cameron Laird <cl****@lairds.us> wrote:

In article <1h*************************@mail.comcast.net>,
Alex Martelli <al***@mail.comcast.net> wrote:
.

Note also that you can freely download all of the code in my book as
http://examples.oreilly.com/pythonia...n-examples.zip (it's just
36 KB). In that same chapter you will find several implementations of .
1. Private e-mail to all the addresses I have for you has
been bouncing.

The aleax.it domain is basically dead mailwise (www.aleax.it still works
fine) -- I can't reach that mailbox unless I'm on the ADSL supplied by
its purveyor (which, of course, only reaches within Italy;-). And
comcast doesn't know how to provide semidecent mail service. But
several addresses of mine should work fine -- I'll try reminding you of
them in private mail.
2. Both 19-7 and 19-8 in the ZIP I found at that URL have
a curious typo that I'll describe this way:
s/_ _/__/g

Yeah, O'Reilly tools have this delightful penchant for inserting a space
between two adjacent underscores, drives me crazy:-(.
Alex

[Cameron Laird]

In article <1h*************************@mail.comcast.net>,
Alex Martelli <al***@mail.comcast.net> wrote:

[Alex Martelli]

Cameron Laird <cl****@lairds.us> wrote:

In article <1h*************************@mail.comcast.net>,
Alex Martelli <al***@mail.comcast.net> wrote:
.

Yeah, O'Reilly tools have this delightful penchant for inserting a space
between two adjacent underscores, drives me crazy:-(.

Alex

Do more of us need to holler at ORA? Is there some technical
reason to allow this craziness to persist?

I can't think of any (though I don't know what quirks of ther typography
they may be working around, it should not affect the code as saved into
zipfiles for download...). ORA's Tools people are a great bunch, but I
take it they're overworked and thus can't give each issue full
attention; apparently this only affects Python, so...:-(
Alex