[omniORB] AMI

[Duncan Grisby]

On Monday 17 November, Kevin Wooten wrote:

> I see an ami directory in cvs named in src/lib/omniORB/omniidl_be/cxx.
> Although it seems the python files were for 3.1. I am inclined to add AMI
> support to omniORB if someone else is not already on it?

I am not aware of anyone working on AMI. It would be great if you
could do it. I'd suggest moving further discussions about it to the
omniorb-dev list.

> Duncan, any suggestions for starting points I have looked through the spec.
> and through the files in the AMI directory.

The AMI related things in the omni3_1_develop branch were written by
David Scott, when he was working as a pre-doc at AT&T for a year. It
was never completed. I'll contact him and ask him if he has any
thoughts about whether it's worth picking up the work he started, or
whether it's best to start again.

My feeling is that it's probably best to start from scratch. First,
because the transport system in omniORB 4 is rather different from the
one in omniORB 3, and second because I think it's possible to do a
much more useful non-threaded (ish) version of AMI.

I think (although I'm not 100% certain) that the omniORB 3.1 AMI
support was using a pool of threads to do the calls. I think a better
approach would be to keep it threadless apart from one manager thread
dealing with dispatching callbacks. omniORB 4 has the ability to
interleave calls on a single connection, which omniORB 3 did not,
which I think would be very helpful here.

The other thing is that the AMI spec uses valuetypes. For omniORB 3.1,
David worked on a minimal valuetype implementation just for supporting
AMI. The omni4_1_develop branch contains a fair bit of support for
valuetypes now, so you'll be able to use real valuetypes.

To progress, please work from the omni4_1_develop branch, since that
is where any AMI support will go. Please read this small page about
source contributions:

  http://omniorb.sourceforge.net/cgi-bin/moin.cgi/SourceContributions

There will inevitably be some ORB core changes to support AMI, but
please try to keep them to a minimum. Ideally, the main body of the
AMI code would go in a separate omniAMI library.

Cheers,

Duncan.

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