Re: OpenMash Debian packages.

[Lloyd Lim <lim@bmrc.berkeley.edu>]

This is going to get a little long as I try to explain some of the Open 
Mash philosophy...

On Thursday 31 January 2002 04:33 am, David Martinez CSIC RedIRIS wrote:
>On Wed 30 Jan 2002 23:13, you wrote:
>>
>> What exactly do you mean by "in a modular way"?
>
>	I'm splitting up otcl and tclcl from the tarball from
> www.openmash.org and making separate packages. They should have been
> separated from openmash sources, don't they?

Well, it depends what your goal is.  An advanced Unix person is likely 
to want all the parts (Tcl/Tk, OTcl, TclCL, GSM, ...) separate so they 
can tinker with them.  As someone working on a Linux distribution, you 
obviously would prefer it this way.  We don't do anything to prevent 
the parts from being interchanged--all of the parts are still available 
from their original distributors.

However, our target audience is a little more complex than usual.  Mash 
is both a set of MBone tools for end users and a programming toolkit 
for researchers.

An end user can download a Mash binary, run the installer, and have a 
working set of MBone tools in under 5 minutes.  No hunting around for 
other libraries that you might need.  Oh, and it all works on Windows 
too.  :)

Many people won't need to do anything more than use the MBone tools.  
But Mash has another level of use...

A researcher or casual developer can download the Mash source, build 
all the code, and have a working set of tools and code to experiment 
with in under 15 minutes.  Oh, and there won't be pages and pages of 
compiler warnings to wonder about.  :)

So we try hard to make the first few steps relatively easy.  The next 
steps get harder...  Trying to actually understand the Mash source code 
isn't so easy.  We have some things in mind to make the learning curve 
a little easier, but it'll take a while.  We're getting there.

More monetary support would help, for any of you out there who might be 
able to assist with funding.

>	Ok. The question raised because there's no much documentation in the
> sources (in fact, in tclcl, as far as I can remember, there's no
> documentation at all, nor license info). I didn't hope too much
> development on otcl and tclcl... :-)

That's right.  There's essentially no documentation on TclCL.  There's 
a little bit in the ns manual.  This is a problem.

>	Good! Uf. The only things I have to fight with now is the licenses in
> CellB, Netvideo, and the XML Parser. I guess that finally openmash
> will be in non-free due to these license problems (see the Debian
> Free Software Guidelines (DFSG)
> http://www.debian.org/social_contract#guidelines).

Interesting.  Yet another definition of "free".  Somewhat in between 
the usual free speech and free beer, closer to free beer.  Mash is free 
beer.

If you really want to make it Debian Free, it wouldn't be that hard.  
See the LICENSE file for info on where the affected code is in the Mash 
source code tree.  XML Parser is only used by "uc", which is 
unsupported.  You can safely delete that from your distribution.

The CellB and Netvideo codecs for vic aren't used much anymore so you 
could remove those if you wanted.

Please make sure that you state clearly somewhere that you've modified 
our source.  It'd also be good to append something to the version 
number to identify it as a Debian variant.

>	Out of curiosity, why didn't/don't you use rat? It's very well
> tested, and has many features. Robert Olson (involved in rat
> development) can asseverate it.

This idea has actually been floated here internally recently.  The idea 
has some merit, although I'd lean against it.  I'll explain why.

As I've explained earlier, Mash is more than a set of tools.  The Mash 
toolkit is a convenient and flexible starting point for experimenting 
with streaming media.

For example, you can fire up a Mash shell, set argc/argv, source in a 
tool like vic, and interactively examine and even tinker with the code 
while the tool is running.  We could add rat to our distribution, but 
you wouldn't be able to work with it this way.

Another example of Mash's flexibility is the code sharing that occurs 
within Mash.  All of the tools sit in the same code tree.  One thing 
that people request, and that we'd like to implement, is a combined 
video/audio tool with a simple interface for people who are used to 
QuickTime, RealPlayer, and/or Windows Media Player.  We have a 
primitive (unsupported) tool like that named collaborator.  It works by 
incorporating classes used by vic and vat.  Again, we could add rat to 
our distribution, but you wouldn't be able to build other tools on top 
of it.

What about taking some of rat's ideas and/or code and using it to 
improve Mash's audio infrastructure?  Yeah, there's lots of stuff we'd 
like to add to our vat.  There's lots of stuff we'd like to do to Mash 
in general.  Jerry Maguire says: "Show me the money!".

If things keep going the way they're going, the MBone community isn't 
going to have *any* actively supported tools soon.

>		Ender.

Quite apropos.

Lloyd