Re: On GIMP and CORBA

[Felix Bellaby <felix pooh u-net com>]

Lauri Alanko writes:

 > > This means that invocations on CORBA objects in the local address
 > > space are only very slightly slower than direct C function calls :-).
 > 
 > Whatever is "slightly" (s)lower.. keeping in mind the infamous note at
 > 9.2.10. Still.. it's good programming practice to have lots of small
 > functions. Making every member access go via the ORB would be unacceptably
 > slow, and only marginally useful in practice, in this case.

Well, what section 9.2.10 says is:

> ...  the ORB mediates all requests to POA based objects. 
> ... This specification does not prohibit (nonstandard) POA
> extensions to support object behavior that is not location
> transparent.

It is perfectly true that POA based objects have to handled in the
standard and slow way. However, the developer using the objects could
not care less whether the object is POA based. What he wants is the
functionality advertised in the IDL and the quicker he gets it the
happier he is. The ORB can achieve this by implementing local objects
without a "proper" POA.

Of course, in an ideal world every object would be quick and
interoperable but that is simply impossible. What is possible is to
provide an ORB which gives the programmer an identical interface to
quick local objects and slow shared objects. This means dropping the
standards and doing the dirty whenever the ORB can establish that
there is simply no reason to follow the standards.

As to being marginally useful, I thought your original point was to
avoid the confusion in the GIMP of having multiple mechanisms for
achieving similar outcomes...

 > > The Fresco toolkit is able to implement its WIDGETS entirely in CORBA 
 > > without unacceptable inefficiency (it does cheat a bit by using a
 > > version of CORBA that is unable to make network connections!!)
 > 
 > Well, if it doesn't support IIOP, it's no real CORBA..
 > 

What is a "real" CORBA ? What is a real C ? The idl and c++ interface
for Fresco look like CORBA to the programmer and they work like
CORBA. Of course, he has to limit himself to local objects but I think 
that may be better than a CORBA which is limited to non-local objects.

I was wrong about dynamic linking. It is a feature of a useful ORB, not 
part of the interoperability standard. There is a section in the CORBA 
specification (17.4.3) on interfacing to the dynamic parts of the MS
OLE specification (aka Automations). I guess the author must have 
thought that dynamically linked libraries would be accessible to CORBA
ORBs:).

Felix