Re: ORBit-cpp & ORBit2 ...

["Douglas S. Keester" <dkeester earthlink net>]

Sam Couter wrote:

> 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.
I would think that making it fully multithreaded would be the way to go. 
I obviously can't speak for everyone though. I remember from reading the 
mailinglist archives and some of the CVS log entries that Elliott made 
some attempts at multithreading and had a difficult time of it. Perhaps 
we could bring the ORBit-mt developers in and consilidate even more. ;-) 
I would be interested to hear what others on the list would have to say 
about this topic.

> > 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 of GNOME's major selling points is its support for multiple 
programming languages. Having support for multiple languages in ORBit is 
only fitting with the spirit of the project. Having C and C++ bindings 
available by default and having a good framework for adding other 
language bidings later definietly increases the overall value of the 
software for use with GNOME.

Perhaps we could make ORBit support multiple languages in a way similar 
to how GCC supports multiple language frontends. This is perhaps a silly 
suggestion, but we could have a system with "plugable" language bindings 
and allow people to choose through autoconf which bindings are supported 
at complie time.

> 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.
I was treating the issue of added complexity as a given. It is good that 
you brought it up though. I would think that through careful coding and 
thoughtful design added complexity could be kept to a minimum.

Well, you all have heard my opinions on the topic. Does anyone else have 
any feelings on this?

-Doug Keester