RE: [INTERFACES] Re: [HACKERS] CORBA STATUS

Surely with autoconf, this becomes less of an issue. I mean, if this is the
only major problem (which it likely isn't, but anyway), then the whole
exercise shouldn't be that hard.

MikeA

>> -----Original Message-----
>> From: Thomas Lockhart [mailto:lockhart(at)alumni(dot)caltech(dot)edu]
>> Sent: Wednesday, November 10, 1999 6:25 AM
>> To: The Hermit Hacker
>> Cc: phd2(at)earthling(dot)net; PostgreSQL-development;
>> pgsql-interfaces(at)postgreSQL(dot)org
>> Subject: [INTERFACES] Re: [HACKERS] CORBA STATUS
>>
>>
>> > Wait...when we talked about this months back, I swore that
>> one of the
>> > conclusions *was* that this was possible...it would
>> involve us doing
>> > wrapper functions in our code that were defined in an
>> include file based
>> > on which ORB implementation was used...?
>> > Basically...
>> > pg_<corba function> maps to <insert mico corba function here>
>> > or <insert orbit corba function here>
>> > or <insert other implementation
>> function here>
>> > Has this ability changed? *raised eyebrow*
>>
>> No, this probably is not necessary since the C or C++ mappings for
>> function calls in Corba are very well defined.
>>
>> What is not fully specified in the Corba standard is, for example,
>> which header files (and by what names) will be generated by the IDL
>> stubber, so each Orb has, or might have, different conventions for
>> include files. This probably impacts server-side code a bit more than
>> clients.
>>
>> There is some interest for some Orbs to try lining up the header file
>> names, but I don't know how feasible it is in the short term.
>>
>> We could probably isolate this into Postgres-specific header files,
>> but there will probably be Orb-specific #ifdef blocks in those
>> headers.
>>
>> - Thomas
>>
>> --
>> Thomas Lockhart
>> lockhart(at)alumni(dot)caltech(dot)edu
>> South Pasadena, California
>>
>> ************
>>