Re: Dynamic Invokation Interface [was: Building ORBit2 on Windows]

["Frank.Rehberger" <Frank Rehberger web de>]

Hi Brent,

I have no Windows dev-host at hand right now to reproduce your
compile/link problem, sorry.

As for the "get_interface" operation. I never used this operation, I
wonder if JacORB or TAO implemented it. The usage looks very inefficient
requiring three remote invocations to get hand onto the operation
declaration in question. Well, but if you invoke the function in
question millions of times later, these three calls do not hurt really.

As I understand the user declares some kind of function prototype in
gnuplot expression, already. So all the IDL-get_interface-issue is about
to get to know if the target function is using float instead of double
or long (32) instead of short (16bit), or wstring instead of string.

Why so complex? You just need to define how the gnuplot primitives (like
double and int) are mapped onto CORBA types, you can go without the IDL
file or interface description. The target service would raise execption
if deserialization might fail.

Once you have obtained the target object reference, just assume the
function name in expression matches the one of service object, with
sound function declaration. If the function is mis-spelled, the service
object will raise exception as well, so don't worry.

Just use CORBA as if it would be JSON or XMLRPC ;)

As for auto vectorized parameters: I know too little about gnuplot
expressions and their possible complexity to be able to say if it is
possible to extract the function automaticly and turn it into a function
call with vector-parameters, keeping identity of the expression

AFAICS, someone implementing the function in C or Java, and attaching
the CORBA API should provide a network-efficient function call as well
using vectors for some parameter. Explicitly declaring how this
vectorized version is to be used.

Regards, Frank