Steve Smith wrote: > Rat is mostly OK, it could just do with a plugin method of handling > drivers rather than the compile-time linking. It's use of MBus for IPC > is interesting but not really appropriate and introduces a whole new > class of problems, sockets or pipes would be better.
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. > Vic has too much reliance on TCL, and its method of the drivers > returning values by building up TCL strings to be eval'ed is just > frightening; that needs to go. i understand your comments but they are really just a matter of personal taste rather than specific technical issues. the issue of tcl, in particular, has come up many times over the years -- many years ago there was a community insisting that the mbone tools should be immediately re-written in java. and then a few years later, it was python. i have programmed pretty extensively in all these languages and the last thing we need here is a language flame war so i'll just observe that each of those languages have their own strengths and weaknesses. however, let me try to shed some light on why tcl was originally chosen for vic. i believe there are two primary reasons. the first is that, at the time, tcl/tk was really the only choice for building cross-platform user interfaces. of course, there are many more options avilable for new projects starting today. but the second reason tcl was chosen originally is that it is simple to write c/c++ code that can be used from tcl. of course it is possible to invoke c++ from python and java as well but doing so is significantly more complex than in tcl. tools such as swig have made this easier but a complex like app like vic is built from a number of individual pieces (e.g., an object for interacting with the network, the rtp protocol stack, video codecs, rendering engines, video capture devices, etc.) these objects are written in c++ but created, destroyed, and managed from a higher level scripting language. given this architecture, it is crucial that the interface between c++ and the scripting language be flexible and easy to extend. 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) > The RTP implementation has problems, mostly to do with the age of the > code. I've started addressing some of the issues (see > http://www-unix.mcs.anl.gov/web-mail-archive/lists/ag-tech/2004/11/msg00202.html), > but other things have taken my time recently; I'm hoping to get back to it > soon though. to be pedantic, you're referring to the rtp implementation in libcommon -- although vic links with that library it does so for encryption support. rat uses that code, but vic has its own implementation of rtp. 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. -Andrew
