Douglas S. Keester <dkeester earthlink net> wrote: > > I have been thinking about this for a few days. I am new to ORBit and > CORBA, so I don't know how difficult this would be. I do think that it > would be a good idea though. My experience with CORBA is only moderate, and I've never looked at the ORBit2 code, so what I have to say might not be all that important. I've just taken on some of the responsibility for maintaining ORBit-C++, but I'm still learning my way through it, so don't consider me any kind of C++ binding guru. ;) > 2) I have also been looking through the mailinglist archives on > http://www.gnome.org/ and have noticed that many of the questions posted > by people who are not ORBit developers are in regards to either C++ or > multithreading. If people want to develop with ORBit in C++ shouldn't we > make it easier for them to do so? Yes, definately. Your comment raises an important question though: Is ORBit2 going to fully support multithreaded operation? I haven't seen a definate answer one way or the other just yet, although I think it's critically important. > 4) By integrating ORBit2 with ORBit-C++ we get more people working on > one codebase and have less duplication of effort. This is a definite win > no matter how you look at it. I think more important than this, and perhaps it's just a subtle difference, is having ORBit-C++ integrated with ORBit2 should allow ORBit-C++ to be synchronised more easily. Some of the internals of ORBit-C++ rely on certain IDL compiler generated stubs, which is a bit nasty. Even if those kind of constructs remain, it'd be much better if they could be maintained as one piece of software (Although I'd obviously prefer to see nasty hackery like that go away). > These are just the few reasons that I could come up with off the top of > my head. I am sure that there are many more better reasons than I have > given. It is my humble, not very well informed, and perhaps a little > naive opinion that integrating ORBit-C++ into ORBit2 is a winning > proposition, depending on how large of an undertaking that would be. > Obviously it has to be worth someone's time to do it. I agree that it seems to be the best way of doing things. I also volunteer to lend some time and what little expertise I have towards seeing it realised. Another reason for integrating ORBit-C++ and ORBit is that it may actually make language bindings for other languages easier. By forcing ORBit code to be general enough to support at least one non-C language binding, things should become easier for other languages. This also goes back to the comment Michael made recently about the C language binding spec not moving on as quickly as other language bindings. One negative that I can thing of is that it would mean that ORBit would not remain C only. The compilation of the C++ code could become conditional based on things like configure script command line options or the existence of a C++ compiler, but just having the code there adds a certain complexity to ORBit that is currently seperated out. Just so you know how I feel about it, I don't see this as being a major problem. The whole idea of integrating ORBit-C++ and ORBit would be to reduce overall complexity, and I think it would do that. Sorry for this post being so long, I guess I had more to say than I thought. -- Sam Couter | Internet Engineer | http://www.topic.com.au/ sam topic com au | tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C
Attachment:
pgpz9stoyvz0d.pgp
Description: PGP signature