sergent:
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 time.
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.
thom:
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.