media tools (was Re: [AG-TECH] AccessGrid 3: What information is available)

Steve Smith ssmith at vislab.usyd.edu.au
Wed May 25 02:04:11 CDT 2005


> why isn't it appropriate?  when you say sockets would be better,
> i assume you mean udp or tcp to the loopback address rather than
> scoped multicast?  although some operating systems don't
> correctly implement loopback multicast, it seems like the logical
> choice since when rat is run, there are 3 processes that all need
> to communicate with each other.  moreover, the mbus is used to
> communicate with external processes (e.g., to do voice-switching
> of vic windows or ostensibly to do lip-synch).  doing this over
> unicast would require some elaborate scheme to allow these
> components to rendezvous with each other.

Sorry, I wasn't very clear in that part ... Agreed, where *independant*
processes need to communicate mbus is a good choice.  However, in
practice Rat uses mbus for communication between the UI and the core.
This in turn requires the packets to be encrypted for security, which
all seem a bit overkill where a pipe would seem more appropriate.

Incidentally (and please correct me if I'm wrong) in practice mbus is
not used between vic and rat, only internally to rat.  The only
reference to mbus I can find in vic is in rtp/source.c, and this just
sends 'rtp.source.playout'.  Rat doesn't appear to pay any attention to
this message (although it sends it's own version).

But to be clear, I'm not saying drop mbus entirely (in fact it should
possibly be used more, for instance for the AG client to dynamically
reconfigure vic and rat rather than constantly restarting them), just
that in practice using mbus for UI/core IPC internally to rat adds
complexity where simpler alternatives exist.

> anyway, re-writing the mbus to use sockets, or porting the
> existing 10,000 lines of tcl in vic to something other
> language (plus all the c++ code that works with and invokes the
> tcl interpreter) would be a major job that would take months,
> if not more, of development just to yield an application with
> the exact same features as the current application but with a 
> bunch of new bugs.  (i'm not suggesting that there aren't
> competent programmers in the community, just that to expect to
> re-write this much code without introducing new bugs would be
> crazy)

True, and this was in many ways my point, that we shouldn't just throw
it away but work with what we have.  I didn't mean to imply we should
rewrite it all, just clean up areas where straight C/C++ would be more
appropriate (i.e. the low-level stuff) and add functionality that
doesn't currently exist (multiple video inputs).  This can be done while
maintaining a working codebase.

> in any case, i don't mean for this to sound hostile but i'm
> concerned that the changes you're proposing could easily
> consume lots of development cycles which are already scarce
> in this community.

I think that a lot of those cycles are currently being spent on the
AGTK, where I think more should be spent on vic and rat, which are
really the core of the AccessGrid.

Cheers,
Steve




More information about the ag-tech mailing list