RE: [Orbit-python-list] win32, orbit2 (separate questions)

[Riggs, R. <RR...@do...>]

MS says "In addition to working directly with these file types, Jet can work
against any data source which provides an ODBC driver. This is called
attaching an external ODBC data source or table."

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q154643

Orbit-python is not necessarily ustable, but, when I used it, O-P was not
robust enough for non-trivial applications. I had issues with memory leaks,
and with threading issues. And I ran into enough problems with the
overridden import function when my dependency tree became even a little
complex that I was forced to give up on it.

Orbit-python was a great learning tool for me. But I quickly ran into it and
Orbit's limitations.

Setting up the omniORB name service is fairly trivial. I created omniORB
RPMs that includes omniNames. And once the ref is in omniNames, you can
reference it with a simple "corbaname" URI. It takes 5-10 lines of Python
code to add the reference to the server. Then fetch it with:

o = orb.string_to_object("corbaname::myserver#myobject")

Lots easier than making your own custom IOR daemon IMHO.



-----Original Message-----
From: dman [mailto:dm...@dm...]

Except that the commercial program we have that uses the database
hooks directly into the Jet engine.  AFAIK that can't be redirected to
an ODBC link.  (that would be the preferred option, though)
...

Did you find orbit-python to be unstable on linux?  The biggest
difference I found, so far, between orbit-python and omniORBpy is that
the latter requires generating python source from the idl.

I also need a way for the client to find the object.  I found out that
I can't just serve the IOR through a socket and have the orb still
work.  Setting up a nameserver seems a bit of overkill for this
application, but I'll work through the docs on it.  I did use a
nameserver once, with java, in a class at school.  Hmm, perhaps I can
exec a separate daemon for serving the IOR.