Re: [HACKERS] More PostgreSQL+CORBA

Поиск
Список
Период
Сортировка
От Jim Penny
Тема Re: [HACKERS] More PostgreSQL+CORBA
Дата
Msg-id 19981116115939.D25387@universal-fasteners.com
обсуждение исходный текст
Ответ на Re: [HACKERS] More PostgreSQL+CORBA  (The Hermit Hacker <scrappy@hub.org>)
Список pgsql-hackers
On Sat, Nov 14, 1998 at 10:38:34PM -0400, The Hermit Hacker wrote:
> On Sat, 14 Nov 1998, Todd Graham Lewis wrote:
> 
> > On Sat, 14 Nov 1998, The Hermit Hacker wrote:
> > 
> > >     For instance, I already have MICO installed because of
> > > koffice...I'd prefer not to have to install *another* one because I want
> > > to use it for PostgreSQL.
> > 
> > If I may, I'd like to put in a plug for ORBit.  DISCLAIMER: I am the
> > GNOME FAQ maintainer.
> 
>     this isn't actually a voting process here...I don't want us locked
> into one implementation.  there are ppl out there that would prefer to use
> mico because it is already installed on their system for some reason or
> another...there should be absolutely no reason why this can't be coded
> generic enough that, through a simple switch when running configure, one
> or the other can be used...no?

You may not want that, but you had better look again.  CORBA defines the
wire transactions very carefully.  It defines the API for invoking 
services very carefully.  It very carefully avoids defining client
initialization, memory layout, API, etc.  There is limited code 
portability.  Yes, conditional compilation will work, but it will be
a lot of effort, probably as much as maintaining a NT/Unix port.
Choose the first ORB carefully!  Internal APIs for service 
implementation is simillarly undefined.

> 
> > Again, I am a GNOME partisan, but I really do think that ORBit is a
> > good choice and a reliable long-term investment.  I encourage the
> > PostgreSQL developers to consider it.
> 
>     I would rather our implementatin be "non-partisan"...what happens
> in a years time, or 6 months, when the "faults" in mico disappear, if they
> do?  at least if we work at staying non-partisan as far as which
> implementation is used, switching will be transparent...all of them will
> already be supported.
> 

Personally I have trouble with both ORBit and MICO.  MICO is far too
memory intensive and SLOW.  Choosing MICO will be an enormous 
performance hit.

I worry about ORBit because I think that  GNOME has seriously 
underestimated the amount of work involved in implementing anORB, not to mention the services.  

If you are going to do this, look carefully before you leap.
At least look at  ORBit, OmniORB2, ACE+TAO, ilu.  Drop MICO
as the performance will simply be too bad.

>     Bear in mind that ORBit and MICO are free implementations...what
> about the commercial ones out there?  Just like we tend to try and support
> each OSs C compiler, I want us to stay non-partisan as far as any
> "external tools" are concerned...
> 

Great ideal, but as CORBA lacks this level of source compatibility,
you can't get there.

>  Marc G. Fournier                                
> Systems Administrator @ hub.org 
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
> 
> 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Taral"
Дата:
Сообщение: RE: [HACKERS] SQL vs. OQL
Следующее
От: "Nugent, Michael P (SAIC)"
Дата:
Сообщение: unsubscribe