[Mono-list] Some news about a CORBA ORB implementation for.Net framework

[Bob Smith]

Hmm... Different idea.
I was more woried about using ORBit for the server side of things then for
the client. Maybe some form of dual library would be interesting. Wraping
ORBit for writing CORBA servers, and a C# Client library so that you can
easily dynamically call other CORBA objects.

On 26 Sep 2002, Michael Meeks wrote:

> Hi Miguel,
>
> On Wed, 2002-09-25 at 23:42, Miguel de Icaza wrote:
> > Forcing the C model that ORBit has into a C# version of CORBA will just
> > lead to a horrible beast as the result.
>
> 	Well - it would be a horrible beast if you had to wrap the generated C
> idl, and compile that etc. etc. - which sucks. Also would not let you do
> arbitrary method invocation.
>
> 	I was not proposing that; I'm proposing interfacing at the guts level
> of ORBit2 which is the C ABI level.
>
> 	I'm assuming here that you have a set of methods that will convert a C#
> 'struct' to an equivalent C layout structure ? [ and VV. ] that's the
> only slightly difficult thing to get right.
>
> 	Then you do:
>
> 	args[0] = &first_arg;
> 	args[1] = &second_arg;
> 	ORBit2_invoke_stub (obj, IMethod_data, &ret, args, NULL, ev);
>
> 	And it all just happens. [ you get the IMethod_data pointer from a type
> library ]. Of course, this has to be compiled into stubs / skels on the
> Mono side - sadly; but it's possible to do fully generically.
>
> 	Thus - no horrors, no inefficiency, indeed - I imagine a dramatic
> efficiency win over re-writing the underlying ORB in C#.
>
> >   You might be able to leverage some "bits" like the IIOP encoding,
> > but it is doubtful how useful that really is.
>
> 	There is no point in re-using some bits, unless you do the above. Doing
> it like this is so powerful because the 'obj' reference you got passed -
> _might_ be implemented in eg. Python - in the current process, and all
> that the 'invoke_stub' does, is pass these args straight to the
> (virtual) de-marshaller in the python binding, resulting in an extremely
> fast cross language in-proc method invocation.
>
> > The in-proc features are cool, but it would need things to be
> > implemented with the ORBit model in mind, and not with a C# mind set.
>
> 	Clearly the above is a naked bridging model, implemented in C; if you
> want to built it on the IByteStream, IDoubleSerializer,
> ICouldPutAnotherObjectHereSoIDid, IMethodInvocationMarshaller etc. ;-)
> then - yes, it's not going to fit into the C# model. All of that is
> implemented in the ORB, in C.
>
> 	Obviously, writing the whole thing in C# will make it marginally more
> portable; at least to the extent that you avoid making Gnome more
> portable, at the cost of making Mono more portable - a choice of dubious
> merit IMHO.
>
> 	Anyway; since it seems the die is cast, I look forward to contrasting
> C#-ORB's performance with that of ORBit2 and various scripting bindins;
> particularly the in-proc performance.
>
> 	Regards,
>
> 		Michael.
>
> --
>  mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot
>
>