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

[dman <dm...@dm...>]

On Thu, Mar 28, 2002 at 02:59:41PM -0700, Riggs, Rob wrote:
| 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

Thanks!  I'll have to test the commercial program in that setup.  From
other reading I was under the impression that "Jet" was the default
db engine for access and that linking odbc drivers was a way of
getting something better than jet.

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

Ok.  Unfortunate.  I'd like to see orbit-python be "the" orb :-).

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

Other than using gnome on a regular basis, and a single lab in a
class, and some curiosity-driven reading, I haven't done much with
CORBA yet.  Certainly nothing non-trivial.
 
| 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")

That INS stuff is new to me.  It looks promising, though.  I don't
expect the coding side to be hard (especially after dealing with sun's
reference implementation for java!), but was thinking more along the
lines of configuration management.

| Lots easier than making your own custom IOR daemon IMHO.

I already have that daemon, it just doesn't work in the same process
as the orb.  It's just an infinite loop that accept()s on a socket,
stuffs the IOR into it, and closes the socket.  You can't get an
easier protocol than that :-).  If my comprehension is correct, then
only the first Connection object needs to be accessed via name or ior.
Everything else will be returned from methods in that object.  I do
agree that a nameserver is the Right Way to do it.

-D

-- 

(E)ventually (M)allocs (A)ll (C)omputer (S)torage