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

[Andrew Swan]

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