Re: freezing ORBit2's API

[jacob berkman <jacob ximian com>]

On Tue, 2001-10-30 at 12:24, Mark McLoughlin wrote:
> Hi there,
> 	I logged a bug (#61584) a while ago that ORBit2 exposes way
> too much internals in its headers. This concerns me because by freezing
> these 'API's we'll be tying ORBit2 down to a commitment that would
> make improvements of the codebase virtually impossible.
> 
> 	The reason for this, it seems, is mainly to cater for language
> bindings down the road. I'm not quite sure as yet how we can cater
> for language bindings while at the same time not freezing major parts
> of the ORB's internals.
> 
> 	So, to make it clear what ORBit2 API is being frozen I've
> wrapped ORB internals in #ifdef ORBIT2_INTERNAL_API and internals that
> are used solely in stubs/skels in #ifdef ORBIT2_STUBS_API. The latter
> will be frozen when binary compatibility is required.
> 
> 	Any objections? If not, I'll release ORBit2-2.3.96 tommorrow.

this breaks libbonoboui:

bonobo-control.c: In function `bonobo_control_notify_plug_died':
bonobo-control.c:66: dereferencing pointer to incomplete type

which corresponds to:

Bonobo_ControlFrame frame;
if (frame != CORBA_OBJECT_NIL && frame->connection != NULL) {

i'll let you two fix it, for now i'll just add a #define
ORBIT2_INTERNAL_API 1 at the top.

jacob
-- 
"Beat mixing is 10000 times more fun than even video games."
	-- bt