Re: Considering ORBit2 for inclusion in LSB

[Patrick Ohly <patrick ohly intel com>]

On Mon, 2006-03-13 at 13:27 -0800, Fujinaka, Todd wrote:
> I'm going back through the ChangeLog, and I'm trying to find the answer
> to several questions that will help decide how to prioritize libraries
> to be included.

I have only started using ORBit2 a few months ago, so please take
my answers below with a grain of salt. I'm sure the long-time users
and developers of ORBit2 will have more profound answers.

> Would you consider ORBit2 to be best known practice? (Did I miss ORBit3
> or some other successor to the library I'm currently researching, or is
> there something else?)

I think ORBit2 is indeed best known practice. Its LGPL license is
compatible with Open Source and commercial applications and technically
it is easier to integrate because of its C language binding and 
implementation. It is used as one of the foundations of the GNOME
desktop which implies that unless something completely unexpected
happens, it should be around for a while.

> How long is binary compatibility maintained? It looks like the API
> hasn't changed (aside from adding new interfaces) for a while, but it's
> taking me a while to go through all the comments in the ChangeLog.

It seems to be pretty stable to me. I haven't seen much discussions
about ongoing development on this list either, so it is probably
mature at this time.

> Is there a test suite that exercises the API or functionality (both
> would be best)?

Yes, there are test programs which to me look pretty comprehensive.
They are in the "test" sub directory.

> Is there a list of programs I could use to demonstrate ORBit2
> functionality?

The echo-client/server programs in the test directory might be good
starting point.

>  Or maybe a list that shows what depends on ORBit2?

rpm -q --whatrequires libORBit-2.so.0 -i
will give you a list. Central GNOME libraries and thus GNOME
applications depend on it.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.