[omniORB] Any suggestions for implementing kylix backend?

[Lars von Wedel]

This is a multi-part message in MIME format.
--------------57FF59BE0500F5A8FDE7447D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

We took a look at Delphi's CORBA capabilities some time ago -- it seemed
like a mess.
Lots of things to be handcoded, ugly handling of sequences, ... Writing
a server was
almost impossible, we finally skipped Delphi...

Lars


Duncan Grisby wrote:
> 
> 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 --
--------------57FF59BE0500F5A8FDE7447D
Content-Type: text/x-vcard; charset=us-ascii;
 name="vonWedel.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Lars von Wedel
Content-Disposition: attachment;
 filename="vonWedel.vcf"

begin:vcard 
n:von Wedel;Lars
tel;cell:++49 172 2043412
tel;fax:++49 241 8888326
tel;work:++49 241 805240
x-mozilla-html:TRUE
url:http://www.lfpt.rwth-aachen.de/Staff/vonwedel.html
org:RWTH Aachen;Lehrstuhl fuer Prozesstechnik
adr:;;Turmstrasse 46;52056 Aachen;;;
version:2.1
email;internet:vonWedel@lfpt.rwth-aachen.de
end:vcard

--------------57FF59BE0500F5A8FDE7447D--