[omniORB] CORBA A/V Strems service - how to

[Gary Duzan]

In Message <Pine.SOL.4.51.0304100640460.28167@niu.ifi.uio.no> ,
   Doru-Catalin Togea <doru-cat@ifi.uio.no> wrote:

=>
=>> .... omniORB
=>> doesn't have an AVStreams implementation, so you'd have to build it
=>> from scratch.
=>
=>What do you mean with "build it from scratch"? Since the A/V Streams
=>specification is pure CORBA IDL I thought it would compile without
=>problems with any ORB's IDL compiler, thus making available the A/V
=>extensions within the framework of that particular ORB. Is there anything
=>else one has to do in order to deploy A/V Streams with an ORB? What else
=>does TAO ORB do besides compiling the A/V Streams IDL?
=>
=>>    BTW, I don't see this as a particular fault of omniORB. My personal
=>> sense, which seemed to be shared by the majority of the folks at the
=>> recent OMG meeting, is that nobody really likes the A/V Streaming spec,
=>> so nobody implements it.
=>
=>I am still confused: How do you implement the A/V Streaming spec.? Isn't
=>it implemented already (like a "library" written in pure OMG IDL)?

   That is true at one level. However, the spec requires and/or implies
a number of activities which should occur when you invoke certain IDL
interfaces, some of which can be done in standard ways. (For example,
the basic handshaking involved when calling bind_devs(), and things
like flowspec parsing and socket communication.) It is these which TAO
implements, and provides a strategy-based framework for implementing
the application-specific parts.

   If all you want to do is compile the IDL, you can so that in any
ORB. As it happens, I do, in fact, compile TAO's AVStreams.idl with
omniidl to generate Python stubs in order to do some monitoring and
control scripting of our AVStreams application, and it works fine.
I don't actually implement MMDevice, StreamEndPoint, etc., for omniORB,
but I don't see any reason why you couldn't.

					Gary Duzan
					BBN Technologies
					A Verizon Company