> 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
