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@alumni.caltech.edu]
>> Sent: Wednesday, November 10, 1999 6:25 AM
>> To: The Hermit Hacker
>> Cc: phd2@earthling.net; PostgreSQL-development;
>> pgsql-interfaces@postgreSQL.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@alumni.caltech.edu
>> South Pasadena, California
>> 
>> ************
>>