[omniORB] AMI

[Duncan Grisby]

On Wednesday 10 January, Jochen Behrens wrote:

[...]
> However, I'm not really sure if it is feasable (with respect to time)
> to volunteer. But I will have a discussion with my employer. Whether I
> can spare time for omniORB development would mainly depend on the
> effort estimations.
>  You mentionend that you already have some implementation ideas. Do
> you think about the callback or polling model (or even both)?
> Personally, I would prefer the callback approach.

What do you mean about callback or polling model?  You mean the
application-level view of AMI?  To be a proper AMI implementation, it
has to support both.

The main challenge in implementing AMI, and the bit I've been
contemplating, is to modify the omniORB connection management code so
that it's possible to start a call on a connection, then carry on
without blocking waiting for a reply. That requires changing some of the
fundamental assumptions in the connection management code. It's somewhat
tricky to extend it, not least because it's a very performance critical
bit of the code.

I can point you at the relevant bits of the code if you're interested in
having a look at it.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --