How to write an API for a Python application?

Discussion in 'Python' started by Gary Kshepitzki, Nov 16, 2005.

  1. 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
     
    Gary Kshepitzki, Nov 16, 2005
    #1
    1. Advertising

  2. Gary Kshepitzki

    Guest

    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.
     
    , Nov 16, 2005
    #2
    1. Advertising

  3. Gary Kshepitzki

    Paul Boddie Guest

    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, Nov 16, 2005
    #3
  4. 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:...
    > 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, Nov 16, 2005
    #4
  5. Gary Kshepitzki

    Eric Brunel Guest

    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+-'])"
     
    Eric Brunel, Nov 16, 2005
    #5
  6. Gary Kshepitzki

    dwelch Guest

    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, Nov 16, 2005
    #6
  7. Gary Kshepitzki

    Mike Meyer Guest

    "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.
     
    Mike Meyer, Nov 16, 2005
    #7
  8. Gary Kshepitzki

    Eric Brunel Guest

    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+-'])"
     
    Eric Brunel, Nov 17, 2005
    #8
  9. 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, Nov 17, 2005
    #9
  10. Gary Kshepitzki

    Paul Boddie Guest

    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, Nov 17, 2005
    #10
  11. Gary Kshepitzki

    Mike Meyer Guest

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


    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 <> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
     
    Mike Meyer, Nov 17, 2005
    #11
  12. In article <>,
    Paul Boddie <> 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 ...
     
    Cameron Laird, Nov 17, 2005
    #12
  13. Gary Kshepitzki

    Mike Meyer Guest

    (Cameron Laird) writes:
    > In article <>,
    > Paul Boddie <> 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 <> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
     
    Mike Meyer, Nov 17, 2005
    #13
  14. In article <>, Cameron Laird <> 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 --
    -- --
    -- http://www.grisby.org --
     
    Duncan Grisby, Nov 18, 2005
    #14
  15. >>>>> Duncan Grisby <> (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 <>
    URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
    Private email:
     
    Piet van Oostrum, Nov 18, 2005
    #15
  16. In article <>,
    Piet van Oostrum <> 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 --
    -- --
    -- http://www.grisby.org --
     
    Duncan Grisby, Nov 18, 2005
    #16
  17. >>>>> Duncan Grisby <> (DG) wrote:

    >DG> In article <>,
    >DG> Piet van Oostrum <> 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 <>
    URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
    Private email:
     
    Piet van Oostrum, Nov 19, 2005
    #17
  18. In article <>, 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.

    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 ...
     
    Cameron Laird, Nov 20, 2005
    #18
  19. Cameron Laird <> wrote:

    > In article <>, 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/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
     
    Alex Martelli, Nov 20, 2005
    #19
  20. In article <>,
    Piet van Oostrum <> 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 --
    -- --
    -- http://www.grisby.org --
     
    Duncan Grisby, Nov 22, 2005
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Shlomo Anglister
    Replies:
    1
    Views:
    429
    Default User
    Aug 2, 2004
  2. Praveen, Tayal (IE10)
    Replies:
    0
    Views:
    390
    Praveen, Tayal (IE10)
    Mar 17, 2005
  3. John123

    Profiling API or Membership API

    John123, Oct 20, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    394
    John123
    Oct 20, 2006
  4. George2

    platform specific API or C standard API

    George2, Nov 12, 2007, in forum: C Programming
    Replies:
    13
    Views:
    767
    Tor Rustad
    Nov 13, 2007
  5. Timothy Grant
    Replies:
    5
    Views:
    435
    Timothy Grant
    Aug 6, 2008
Loading...

Share This Page