[omniORB] Any suggestions for implementing kylix backend?

[Daniel Weber]

Thanks for the advice, I know it's not going to be easy, but I'm just doing 
it for the learning :-)

I looked at the Delphi Corba bindings, but they're pretty upfront that the 
bindings are designed to make interoperability with COM as easy as possible.  
For that reason, they don't have any native stubs for even such things as 
arrays - almost everything gets passed as an OleVariant, which seems kind of 
basically broken to me.  If I actually get anything running, maybe I'll make 
the bindings for both, but for a start it seems much more logical to go with 
a mapping that more closely resembles the C++ mapping.

I'll start looking at the python bindings tonight.  Which implementations do 
I have to implement?  I presume the ORB and POA are essential, but which of 
the other ones?   Linking to C isn't an issue with Kylix, but I'm worried 
about C++ (passing around object references).  I guess I'll know more when I 
look at the python stuff.

Implementing the Any class should be particularly interesting...

daniel
 >
 >On Sunday 1 July, Daniel Weber wrote:
 > > I've been messing aroudn this weekend looking at creating some way
 > > of getting CORBA functionality in Kylix.  OmniOrb would appear to be
 > > an excellent vehicle for this (although I'm looking at ORBit as
 > > well, mostly b/c of it's object activation framework).
 >
 >As far as I know, ORBit's object activation framework is just an
 >application, so it could be used from other ORBs. I could be wrong,
 >though.
 >
 >> Any suggestions out there on how feasible it is to create a backend for
 >> omniidl to create .pas files?  As far as I know, there isn't a standard > 
> for object pascal mappings (and I have no experience with the Enterprise
 > >Delphi implementation), so it's not going to be pretty.
 >
 >Writing the IDL compiler back-end is actually one of the easiest parts
 >of doing a language binding from omniORB to another language. You
 >certainly shouldn't be thinking about writing the back-end until
 >everything else is sorted out. You do have to think about what the
 >back-end should output, but it's premature to automate the stub
 >generation until you're certain what it should be.
 >
 >For the language mapping, it would seem sensible to use whatever
 >Visibroker does, unless that is particularly badly designed.
 >Compatibility with an existing implementation would be better than a
 >whole new binding.
 >
 >I don't know what Dephi's C++ interaction is like. You will need to
 >make all of the public CORBA interfaces, as well as probably some
 >internal omniORB things, accessible from Delphi. With any luck, it's
 >easy to interface Delphi with C++.
 >
 >The best approach to start figuring out what you need to do is to try
 >to follow how the C++ stubs go about making and dispatching calls.
 >Then look at omniORBpy, and see how it hooks in to the omniORB
 >internal structure to achieve the same thing from Python. It might not
 >be sensible to base a Delphi binding on the schemes used by omniORBpy,
 >but it will certainly give you some ideas.
 >
 >If you are going to attempt this, it's best to start out with the
 >omniORB 4.0 preview. A lot has changed since omniORB 3, and it seems a
 >bit pointless for you to be working with an old version.
 >
 >This won't be a small undertaking, I'm afraid.
 >