Re: ORBit status?

[Tom Tromey <tromey cygnus com>]

>> Huh? CORBA doesn't explicitly support it (unless it's part of some
>> auxiliary CORBA document I haven't seen yet). Sure, you can pick
>> one of the language bindings, for instance the C language bindings,
>> and decide that the binary interface will be that + the standard C
>> calling conventions for the system. I don't consider that a good
>> decision: I'd explain the reasons why, but I'm not sure this is
>> what you mean.

Miguel> At least the CORBA document I have here (corba-98-02-01.pdf)
Miguel> in section 2.2 (Example ORBs) talks about this specific case
Miguel> (2.2.4).

Yeah.

I'd still like to hear David's proposal.  I don't think anything is
really wrong with using the standard ("C") ABI for a system, but I'm
willing to listen to alternate proposals.

>> But if my client app just calls the method (in C or C++, say), it
>> will block waiting for a reply.

Miguel> I am not sure how the "dispatcher" plugs in here (concept
Miguel> stolen from MICO's GtkDispatcher).  Someone more knowledgable
Miguel> should comment on this.

The dispatcher is exactly the mechanism to use.  It's easy to allow
pluggable dispatchers, too, so that ORBit won't be Gtk-specific.  Both
ILU and MICO do this.

In some cases you really do need the dispatcher to be pluggable.  For
instance, when integrating with Guile you'd like to use its
`scm_internal_select' (I hope I got the name right) mechanism.

Tom