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

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

On Thu, Mar 28, 2002 at 01:46:19PM -0700, Riggs, Rob wrote:
| Have you considered other architectural design options? 

Yes.

| It's fairly easy to move Access tables into a relational database
| (PostgreSQL, for example), and use ODBC table links to get at the
| data from within Access.  You can then use ODBC to access the
| database from both applications, and eliminate the need for the
| additional CORBA middleware component. I think this is a lot less
| work up front, and will be easier to maintain in the long run.

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)

| However, if you are stuck on using CORBA,

Commercial ODBC drivers for UNIX->Access are extremely expensive.  I
didn't find any free ones.  (this is a non-profit organization; $2k
software components aren't very feasible)

| have you considered omniORB?

I got hello world to work with it.  If I can't get orbit-python for
windows then I'll be using it, most likely.

| I've used it under Linux and NT4, and find it much more stable than
| Orbit-python.

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.

Thanks,
-D

-- 

All a man's ways seem innocent to him,
but motives are weighed by the Lord.
        Proverbs 16:2