[omniORB] Any suggestions for implementing kylix backend?
Duncan Grisby
dgrisby@uk.research.att.com
Mon, 02 Jul 2001 13:58:40 +0100
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.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --