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 _______________________________________________ orbit-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/orbit-list
