Thread
-
CORBA STATUS
Mark Proctor <mail-list@molnir.com> — 1999-11-09T01:38:35Z
I'm currently studying for a Masters at Brunel University, London. I was looking for a thesis and since I had an interest in Opensource development and databases I thought that I would like to work on PGsql. As I also had an interest in trying to understand CORBA and other related technologies it made sense that I try and work on a project that ties PGsql and CORBA together in some way. Marc G. Fournier and Bruce Momjian were contacted with regards to this and they seemed to think that there was room for me to work on this, although at this stage I hadn't gone through the mailing list. since then I've finally got PGsql up and working and I'm now embarking on understand how to system actual works. I thought a good place to start with my research would be to go through the mailing lists to try and see the current status for development in this area. I did this for several hours trying to get the current take on CORBA with regards to PGsql. It seems there was a lot of initial talk back in Nov 1998 on the hackers list with the first thoughts of some sort of CORBA implementation. The conversation orientated over 2 main areas; which ORB and implementation methods, with some peoples offering to work on this. It was then suggested that the converstaion take place in the interfaces mailing list. I've since been over some of this but find it very difficult to understand the current status with regards to PGsql and CORBA. I've seen many references to people who have developed a project that allows them to work with PGsql via CORBA, but non of this seems to be part of the main project or system. There is some reference to Micheal Robinson working on an implementation but again I'm not sure how this fits in-http://www.postgresql.org/mhonarc/pgsql-interfaces/1998-11/msg00090.html Is there room for me to work on this project in such a way that it is adequate for my masters. If anyone is working on this, or has a good knowledge of the current status of the CORBA implementation for PGsql can you please let me know, so I can know whether to get started on this or not. The reference thread for my initial point of contact with Marc G. Fournier and Bruce Momjian and how they think I should attack the project is - http://www.postgresql.org/mhonarc/pgsql-hackers/1999-09/msg00076.html Regards Mark Proctor email : m.proctor@bigfoot.com
-
Re: [HACKERS] CORBA STATUS
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-11-09T02:09:51Z
> Is there room for me to work on this project in such a way that it is > adequate for my masters. If anyone is working on this, or has a good > knowledge of the current status of the CORBA implementation for PGsql can > you please let me know, so I can know whether to get started on this or not. > The reference thread for my initial point of contact with Marc G. Fournier > and Bruce Momjian and how they think I should attack the project is - > http://www.postgresql.org/mhonarc/pgsql-hackers/1999-09/msg00076.html I know of no one working on it. There were two ideas as I remember. One was to replace our existing client/server communication with corba, and the second was to have a corba server that accepted corba requests and sent them to a PostgreSQL server. I prefer this second approach as I think CORBA may be too much overhead for people who don't need it. Our current client/server communication is quite efficient. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] CORBA STATUS
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-11-09T07:55:37Z
> > Is there room for me to work on this project in such a way that it is > > adequate for my masters. If anyone is working on this, or has a good > > knowledge of the current status of the CORBA implementation for PGsql can > > you please let me know, so I can know whether to get started on this or not. > > The reference thread for my initial point of contact with Marc G. Fournier > > and Bruce Momjian and how they think I should attack the project is - > > http://www.postgresql.org/mhonarc/pgsql-hackers/1999-09/msg00076.html > I know of no one working on it. Right. No one is working on it, or if they are they haven't told anyone. It's all yours ;) > There were two ideas as I remember. > One was to replace our existing client/server communication with corba, > and the second was to have a corba server that accepted corba requests > and sent them to a PostgreSQL server. I prefer this second approach as > I think CORBA may be too much overhead for people who don't need it. > Our current client/server communication is quite efficient. Actually, our current protocol is about the best you can do assuming that you don't have something as powerful as Corba to do it right. In the time since Corba was first brought up wrt Postgres, I have been involved with extensive Corba development for a family of systems at work. It is a tremendously powerful standard, though just re-implementing the existing interfaces using Corba would probably defeat the power and flexibility Corba can give you. Postgres currently avoids endian and other data representation issues between client and server by converting all data to strings. Corba can efficiently pass binary info back and forth, automatically handling endian issues *if necessary*. This alone should make a Corba-based interface using native internal representations of data types more efficient both in speed and size than our current scheme. Using Corba's DII, we might even cope with Postgres' type extensibility features in a transparent manner. One trick will be to choose a Corba ORB to use on the server side. It should probably be a C implementation, though Corba more naturally maps to an OO language such as C++. It will be a trick to find an ORB which is supported on as many platforms as Postgres is. One of the most portable ORBs is TAO, which we are using at work, but that is C++ and involves 1.3GB of disk space to fully build!! But the runtime sizes are pretty reasonable, adding just a few megabytes of shared libraries to a plain-vanilla client/server application. imho it will be extremely difficult to find an ORB which could be injected directly into the Postgres server. It would likely reduce the number of platforms Postgres runs on, and would not be considered acceptable. For a first cut, you might consider Bruce's "plan B", which involves writing a new client to the Postgres backend, which would be a Corba server to other clients. That would allow you to start working with Corba without hacking up the backend early on. At the extreme end, fully Corba-ized Postgres server is an intriguing thought, allowing backend to be broken up into distributable modules. Have fun thinking about the possibilities... - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California -
Re: [HACKERS] CORBA STATUS
Brian E Gallew <geek+@cmu.edu> — 1999-11-09T13:15:30Z
Then <lockhart@alumni.caltech.edu> spoke up and said: > imho it will be extremely difficult to find an ORB which could be > injected directly into the Postgres server. It would likely reduce the > number of platforms Postgres runs on, and would not be considered > acceptable. On the other hand, this is where the power of configure comes into play. Assuming we have servers for multiple ORBs, configure can look to see what's installed (TAO, Orbit, whatever) and then build only that server. -- ===================================================================== | JAVA must have been developed in the wilds of West Virginia. | | After all, why else would it support only single inheritance?? | ===================================================================== | Finger geek@cmu.edu for my public key. | =====================================================================
-
Re: [HACKERS] CORBA STATUS
Marc G. Fournier <scrappy@hub.org> — 1999-11-09T14:12:56Z
On 9 Nov 1999, Brian E Gallew wrote: > Then <lockhart@alumni.caltech.edu> spoke up and said: > > imho it will be extremely difficult to find an ORB which could be > > injected directly into the Postgres server. It would likely reduce the > > number of platforms Postgres runs on, and would not be considered > > acceptable. > > On the other hand, this is where the power of configure comes into > play. Assuming we have servers for multiple ORBs, configure can look > to see what's installed (TAO, Orbit, whatever) and then build only > that server. ACtually, I believe Thomas was referring to those platforms that we currently support that have no ORBs available to them...being a "purely C" server so far, how many of our currently supported platforms are we going to cut off with this? Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] CORBA STATUS
Brian E Gallew <geek+@cmu.edu> — 1999-11-09T14:44:27Z
Then <scrappy@hub.org> spoke up and said: > ACtually, I believe Thomas was referring to those platforms that we > currently support that have no ORBs available to them...being a "purely C" > server so far, how many of our currently supported platforms are we going > to cut off with this? But that's just it: we're not cutting anybody off. We may not have a CORBA server available for that platform, but the standard server will continue to work quite nicely. I guess that I'm looking at this more as contrib code than as mainstream, required functionality. Besides, once the CORBA server is built on a platform that can support it, clients can run from (basically) anywhere. -- ===================================================================== | JAVA must have been developed in the wilds of West Virginia. | | After all, why else would it support only single inheritance?? | ===================================================================== | Finger geek@cmu.edu for my public key. | =====================================================================
-
Re: [HACKERS] CORBA STATUS
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-11-09T15:06:53Z
> > > imho it will be extremely difficult to find an ORB which could be > > > injected directly into the Postgres server. It would likely reduce the > > > number of platforms Postgres runs on, and would not be considered > > > acceptable. > > On the other hand, this is where the power of configure comes into > > play. Assuming we have servers for multiple ORBs, configure can look > > to see what's installed (TAO, Orbit, whatever) and then build only > > that server. In the long run, that would be neat. In the short run, the details of each ORB vary considerably wrt, for example, the names and numbers of #include files. So it would complicate the code to try bringing along two ORBs at the beginning. We might expect the ORBs to converge a bit over time, so this will be easier later. > ACtually, I believe Thomas was referring to those platforms that we > currently support that have no ORBs available to them...being a "purely C" > server so far, how many of our currently supported platforms are we going > to cut off with this? Don't know, and it doesn't matter (yet). We shouldn't avoid the issue without someone looking at it further just because we *might* lose some platforms; better to push it farther as a demonstration at least before deciding that it isn't a possibility. Anyway, I know that at least one ORB, TAO, runs on many more types of platforms than Postgres does (e.g. VxWorks, Lynx, Solaris, NT, ...), though Postgres runs on more Unix-style platforms. But that particular ORB is not a good candidate for us, for reasons I already mentioned (C++, large build size, poor configure support). - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California -
Re: [HACKERS] CORBA STATUS
Dmitry Samersoff <dms@wplus.net> — 1999-11-09T16:56:19Z
On 09-Nov-99 Thomas Lockhart wrote: >> > > imho it will be extremely difficult to find an ORB which could be >> > > injected directly into the Postgres server. It would likely reduce the >> > > number of platforms Postgres runs on, and would not be considered >> > > acceptable. >> > On the other hand, this is where the power of configure comes into >> > play. Assuming we have servers for multiple ORBs, configure can look >> > to see what's installed (TAO, Orbit, whatever) and then build only >> > that server. > > In the long run, that would be neat. In the short run, the details of > each ORB vary considerably wrt, for example, the names and numbers of >#include files. So it would complicate the code to try bringing along > two ORBs at the beginning. We might expect the ORBs to converge a bit > over time, so this will be easier later. > >> ACtually, I believe Thomas was referring to those platforms that we >> currently support that have no ORBs available to them...being a "purely C" >> server so far, how many of our currently supported platforms are we going >> to cut off with this? > > Don't know, and it doesn't matter (yet). We shouldn't avoid the issue > without someone looking at it further just because we *might* lose > some platforms; better to push it farther as a demonstration at least > before deciding that it isn't a possibility. > > Anyway, I know that at least one ORB, TAO, runs on many more types of > platforms than Postgres does (e.g. VxWorks, Lynx, Solaris, NT, ...), > though Postgres runs on more Unix-style platforms. But that particular > ORB is not a good candidate for us, for reasons I already mentioned > (C++, large build size, poor configure support). IMHO, There has no ideal ORB for all platforms. we use ORBacus (http://www.ooc.com), because it's the only known for me ORB, working without threads so its really faster and more stable than another ones under FreeBSD, but it's not free. May be it is better make directory CORBA under interfaces subtree and time-to-time put objects for differend ORB's inside, into separate directory. Probably, It's better to make separate configure for some parts of postgres distributions to allow users to build/upgrade parts of postgres i.e psql or perl interface --- Dmitry Samersoff, dms@wplus.net, ICQ:3161705 http://devnull.wplus.net * There will come soft rains ...
-
Re: [HACKERS] CORBA STATUS
Goran Thyni <goran@kirra.net> — 1999-11-09T17:15:06Z
I have done some research into slapping a CORBA interface onto the PgSQL server. I have looked at ORBit but my findings seems to apply to most CORBA implementations. I found that there is a fundamental problem concerning the difference in process models in pgsql and the POA (Portable Object Adaptor) in CORBA implementations. AFAICS, POA assumes a threaded server while PgSQL uses a traditional forking model. I see 3 ways to resolve this: 1. Adapt the PgSQL server to use threads instead of forking. I am not sure we want to do this since it is a major undertaking and will not help the rock solid stability we expect from a professional RDBMS. 2. Write a Forking Object Adaptor (FOA). Would be a big job but it would benefit other similar projects. A FOA would have to be rewritten for every ORB. If you want to do this I suggest starting with ORBit since it is all C and thereby easier to slap onto PgSQL. 3. Extend postmaster to proxy CORBA requests. Postmaster could fork of postgres processes on incoming connections. Postmaster will keep listening and proxying request and responses to/from the postgres process through some kind of IPC. This will make the postmaster multithreaded and the postgres processes still singlethreaded. It is doubtful if the gains: - standard-based protocols - less code to maintain (?) justifies the amount of work required. An easier way out is to, as suggested by others, implement the CORBA-service outside the server itself. It will in some cases give some latency related performance degrading compared to a in-server implementation. One effort to do something like that (and more) is gnome-db. Check out http://www.gnome.org/gnome-db/ regards, ----------------- Göran Thyni On quiet nights you can hear Windows NT reboot!
-
Re: [HACKERS] CORBA STATUS
Adriaan Joubert <a.joubert@albourne.com> — 1999-11-09T17:15:17Z
> ACtually, I believe Thomas was referring to those platforms that we > currently support that have no ORBs available to them...being a "purely C" > server so far, how many of our currently supported platforms are we going > to cut off with this? OmniORB http://www.uk.research.att.com/omniORB/omniORBForm.html runs on most Unix-like platforms. It is free and it is pretty fast. I used it a about 18 months ago and it was already pretty good then. Adriaan
-
Re: [HACKERS] CORBA STATUS
Oleg Broytmann <phd@phd.russ.ru> — 1999-11-09T18:25:23Z
On Tue, 9 Nov 1999, Dmitry Samersoff wrote: > > Anyway, I know that at least one ORB, TAO, runs on many more types of > > platforms than Postgres does (e.g. VxWorks, Lynx, Solaris, NT, ...), > > though Postgres runs on more Unix-style platforms. But that particular > > ORB is not a good candidate for us, for reasons I already mentioned > > (C++, large build size, poor configure support). > > IMHO, There has no ideal ORB for all platforms. > we use ORBacus (http://www.ooc.com), > because it's the only known for me ORB, working without threads > so its really faster and more stable than another ones under FreeBSD, > but it's not free. FNORB - http://www.dstc.edu.au/Products/Fnorb/ Fnorb is a CORBA 2.0 ORB written in Python. Free for non-commercial use. Oleg. ---- Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net Programmers don't die, they just GOSUB without RETURN. -
Re: [HACKERS] CORBA STATUS
Marc G. Fournier <scrappy@hub.org> — 1999-11-09T21:39:20Z
Whomever does this implementation, or works on this, needs to bear in mind that there are several different ORBs out there, and the code should be written in such a way that *I* can use MICO, Oleg here can use Fnorb, someone else can use ORBit, etc...I personally don't want to have to go ut and grab <INSERT ORB of the Day here> just so that I can use CORBA, when I already have Mico installed for other software... On Tue, 9 Nov 1999, Oleg Broytmann wrote: > On Tue, 9 Nov 1999, Dmitry Samersoff wrote: > > > Anyway, I know that at least one ORB, TAO, runs on many more types of > > > platforms than Postgres does (e.g. VxWorks, Lynx, Solaris, NT, ...), > > > though Postgres runs on more Unix-style platforms. But that particular > > > ORB is not a good candidate for us, for reasons I already mentioned > > > (C++, large build size, poor configure support). > > > > IMHO, There has no ideal ORB for all platforms. > > we use ORBacus (http://www.ooc.com), > > because it's the only known for me ORB, working without threads > > so its really faster and more stable than another ones under FreeBSD, > > but it's not free. > > FNORB - http://www.dstc.edu.au/Products/Fnorb/ > Fnorb is a CORBA 2.0 ORB written in Python. Free for non-commercial > use. > > Oleg. > ---- > Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net > Programmers don't die, they just GOSUB without RETURN. > > > ************ > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] CORBA STATUS
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-11-10T03:01:59Z
> Whomever does this implementation, or works on this, needs to bear in mind > that there are several different ORBs out there, and the code should be > written in such a way that *I* can use MICO, Oleg here can use Fnorb, > someone else can use ORBit, etc...I personally don't want to have to go > ut and grab <INSERT ORB of the Day here> just so that I can use CORBA, > when I already have Mico installed for other software... Then forget it. Corba implementations don't work this way (yet). Sorry you're not interested... - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California -
Re: [HACKERS] CORBA STATUS
Marc G. Fournier <scrappy@hub.org> — 1999-11-10T04:07:13Z
On Wed, 10 Nov 1999, Thomas Lockhart wrote: > > Whomever does this implementation, or works on this, needs to bear in mind > > that there are several different ORBs out there, and the code should be > > written in such a way that *I* can use MICO, Oleg here can use Fnorb, > > someone else can use ORBit, etc...I personally don't want to have to go > > ut and grab <INSERT ORB of the Day here> just so that I can use CORBA, > > when I already have Mico installed for other software... > > Then forget it. Corba implementations don't work this way (yet). 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* Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] CORBA STATUS
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-11-10T04:25:27Z
> 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 -
Re: [HACKERS] CORBA STATUS
Vince Vielhaber <vev@michvhf.com> — 1999-11-10T11:22:45Z
On Wed, 10 Nov 1999, Thomas Lockhart wrote: > > 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. Is there any reason configure couldn't handle this? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h> Have you seen http://www.pop4.net? Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ========================================================================== -
Re: [HACKERS] CORBA STATUS
Marc G. Fournier <scrappy@hub.org> — 1999-11-10T14:58:12Z
On Wed, 10 Nov 1999, Thomas Lockhart wrote: > > 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. Right, which is something that I thought we had pseudo-agreed upon the last time through, that we woudl most likely require this...hadn't realized it was for 'Orb-header files', but, IMHO, that's no worse then putting in HAVE_MICO vs HAVE_ORBIT blocks and having it a configure option... See...I am interested, just not interested in having us tied to one "vendor"...:) Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] CORBA STATUS
Marc G. Fournier <scrappy@hub.org> — 1999-11-10T14:58:47Z
On Wed, 10 Nov 1999, Vince Vielhaber wrote: > On Wed, 10 Nov 1999, Thomas Lockhart wrote: > > > > 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. > > Is there any reason configure couldn't handle this? As simple as a '--with-corba=mico' configure option ... or, I would think? Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] CORBA STATUS
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-11-10T15:43:46Z
> See...I am interested, just not interested in having us tied to one > "vendor"...:) I know. That still doesn't keep me from being in a bad mood after spending 3.5 hours at the dentist yesterday :(( On the Corba fork vs thread issue: It is true that the server process would need to be handed off to the client in a different manner from the postmaster; with Corba you don't just fork onto a different port and be done with it. However, the postmaster *could* start up a server process and return an IOR to the client, which givs the client a direct handle to the server. The client would then initiate contact directly with the server, and the postmaster is no longer involved. afaik you could still fork in the postmaster, though whether our streamlined tricks would work with every Orb is not certain. But that is an optimization for our specific forking implementation, not a fundamental feature. As I mentioned, the real performance benefits come from having an optimized query connection which bypasses the *expensive* string conversions we currently use to pass data around. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California -
Re: [HACKERS] CORBA STATUS
Christof Petig <christof.petig@wtal.de> — 1999-11-30T04:44:10Z
Mark Proctor wrote: > I'm currently studying for a Masters at BrunelUniversity, London. I > was looking for a thesis andsince I had an interest inOpensource > development anddatabases I thought that I would like to work onPGsql. > As I also had an interest in trying tounderstand CORBA and other > related technologies itmade sense that I try and work on a project > that tiesPGsql and CORBA together in some way. > > Marc G. Fournier and Bruce Momjian were contacted withregards to this > and they seemed to think that therewas room for me to work on this, > although at thisstage I hadn't gone through the mailing list. > > since then I've finally got PGsql up and working andI'm now embarking > on understand how to system actualworks. I thought a good place to > start with myresearch would be to go through the mailing lists totry > and see the current status for development in thisarea. I did this for > several hours trying to get thecurrent take on CORBA with regards to > PGsql. It seemsthere was a lot of initial talk back in Nov 1998 onthe > hackers list with the first thoughts of some sortof CORBA > implementation. The conversation orientatedover 2 main areas; which > ORB and implementationmethods, with some peoples offering to work on > this.It was then suggested that the converstaion take placein the > interfaces mailing list. I've since been oversome of this but find it > very difficult to understandthe current status with regards to PGsql > and CORBA.I've seen many references to people who have developed > a project that allows them to work with PGsql viaCORBA, but non of > this seems to be part of the mainproject or system. There is some > reference to Micheal Robinsonworking on an implementation but again > I'm not surehow this fits > in-http://www.postgresql.org/mhonarc/pgsql-interfaces/1998-11/msg00090.html > > Is there room for me to work on this project in such away that it is > adequate for my masters. If anyone isworking on this, or has a good > knowledge of thecurrent status of the CORBA implementation for > PGsqlcan you please let me know, so I can know whether toget started > on this or not. The reference thread formy initial point of contact > with Marc G. Fournier andBruce Momjian and how they think I should > attack theproject is > -http://www.postgresql.org/mhonarc/pgsql-hackers/1999-09/msg00076.html > > Regards > > Mark Proctor > email : m.proctor@bigfoot.com Dear Mark, as this reply stuck between my brain and my fingers for two weeks now, it might come too late. But Corba defines a Facility (or a Service) to access object oriented databases via a standardized interface. Since Postgres is an OORDBMS (there is a definitely shorter abbreviation), it might suit it well to offer such an interface. I never looked too deep into the standard document but if you are interested, I'll look up the exact location. Since this does not interfere with Postgres' internals it should be much easier to do. And since a redesign (for speed) of the backend interface would not provide new features, I would suggest taking a look into this area. IMHO the Corba specs should get more attention. I really like these standardization efforts, though they rarely affect everyday (free) programming environments. Regards Christof (which was tempted to implement them some month ago but decided to build actual programs on now-available and (to me) well known technology (ecpg driven Corba objects)).