There is the freely available MPEG-1
library based on code from Berkley that will return a
frame for decoding. I wrote a FreeBSD console app to view
MPEG-1 video, but because it actually returns a full frame
instead of the differences (kinda hard to do), it's a bit
more complex, but for RTP data, you probably don't need
30/24fps speed. It was very simple to write. Should do the
job for you.
Digest Auth doesn't cut it as it still requires a clear
password sent to the otherside. As for the others, there
isn't any rfc that tells how these are standarized. Sure
you can write your own, but then that's your own. So, still
no strong auth.
As for the design document, it should include all
features you will want to include in the product and not
include any implementation details. Implementation is
later, the design document is to describe what you are going
to do, and what features you are going to include so that
when you start implementing it, you don't end up doing extra
work for what isn't in the design document, or you forget to
include features. SVN's design doc is more of a basic
implementation documentation as it includes this is how we
are going to do it.
If you had know/pointed me to future.texi earlier in the
discussion, less misunderstanding would of happened, but at
least I did finally find that you guys are planning on it
(sounds like you didn't even know about it before), but
haven't included it as part of your design.
As for it being Open Source, that's just spiffy, but to
many people think of open source is the end all solution.
What really open source have shown is that code sharing
between groups/orginizations is a good thing. Do you think
FreeBSD would be so successful if it wasn't for the GNU gcc
compiler, nvi and other projects that are out there? It all
comes down to being able to share code. People reimplement
code all the time including stupid mistakes such as
skiplists. If everyone wrote their own, it'd be a waste of
With Inter-repository communication and public/private
key authentication, it becomes easy for people to share code
and follow bug fixes that have happened. Imagine being able
to run a simple command sc update and suddenly have
all of the latest code for the 15 different libraries your
product has. Now that be a 21st century feature.
This would also be equally applicable to commerical ventures
as free ones. It would allow a company to sell certain
releases of the library and allow them to fetch patches and
all those goodies.
So, when will Subversion 1.0 be released? Any general
idea? This year? 2001? 2002? Will Inter-repository
communication make it up to the design document so it's not
one of those well, if we have time, we'll get around to it,
but we don't really care about it so it isn't going to be
part of the project unless someone contributes code to do
it? Thanks for the information, and I do hope that the
project goes well.
Sounds like your experience was pretty similar to mine while
I was in Melbourne, Australia. Danced with this girl for a
while, get her mobile, run into her a couple days later, and
I realize that she's a lesbian.