For those of you who are interested in what the patent applications are about but do not feel like sifting through them in search of actual information, I posted an analysis of the "Interdiction..." patent on the "Challenge of P2P" blog.
As an aside, and as discussed in the blog post to which I refer, what they characterize as hash spoofing does not require to break any cryptographic primitives. It merely refers to a form of false advertising.
Hmm. Actually, it does not seem to me that the reason why he is leaving is clear - at least, not from the article mentioned or from any of the comments that I've been able to read. JWZ left because he thought that Mozilla had been more a failure than a success (source: his web site) and did not have fun anymore working for a big corporation. At least, that's what I understood from what he said on the subject.
In some sense, the critiques that applied to Mozilla on April, 1st 99 (when jwz left) still more or less apply today: the product is not in a deliverable state. I mean, it's an alpha release, with various degrees of stability depending on the environment you're running it on, and that's definitely not a deliverable. Not yet, at least.
I don't contribute to the project by lack of time (insert your favorite excuse here) and because I'm not a good enough coder to participate in such a big project, where the code base is so huge and complex.
But I have a hard time understanding why Mozilla takes so long to take off when something like Linux or Free BSD, whose source code size is probably bigger than Mozilla's (correct me if I'm wrong), are still very active. It's definitely not the lack of people, or the lack of skills, but I'd like to understand where it comes from.
Complexity/messiness of the source? Communication problems? Lack of support from Netscape (that was one of JWZ's rants)? Or something else?
In short: what I get from this is that Open Source is not the solution to all of our problems. Sometimes, it doesn't work very well. At least, not as well as it could. And Mozilla seems to be an example of that, unfortunately.
No. Once you've got the codec, the rest is not very difficult to create (theoretically). You can basically rely on the usual transport protocols (that are in fact in the application layer), that is:
RTP (Real Time Protocol) for the actual transport
RTCP (Real Time Control Protocol) for controlling the bit-rate, and possibly do some dynamic adjustment of the encoding scheme
RTSP (Real Time Streaming Protocol) which is a sort of "remote" control (it's sort of like HTTP/1.1 applied to a different context)
or ST-II for the old-timers, but I wouldn't advice it:) (ST-II is also known as IPv5 for those of you who care)
RTP, RTCP and RTSP's designs are not proprietary, and are described in RFC's 1112, 1889 (I've myself given a tutorial for a class on that, any interested parties can get the slides there).
They are used in the Real Players of all sorts.
As for the person who pointed out that Real doesn't scale well, I think it depends on what you call scaling. Typical implementations tend to be unicast, but people tend to switch to multicast (e.g., broadcast.com) which should scale better (less congestion). Unfortunately having scalable AND reliable multicast is still a topic of ongoing research.
Many people have been working on this since Deering's thesis in 86 (there is no Multicast TCP for obvious reasons), and so far, the results are so-so.
In short, the challenges are multi-fold:
What kind of streaming protocol do we want to use?
Do we aim at multicast or unicast transmission?
What codec do we want to use (RTP, RTCP, and other streaming protocols do not provide any information on how to compress the data, it's NOT their job - their job is to provide mechanisms for shipping the data and being able to reassemble it, but you've gotta specify which kind of compression scheme you want to use, thus there's no conflict between using RTP and MPEG for instance).
Which format would be best under X? (I've gotta admit I'm unsure...)
This was redundant with some other posts, but it seems like most people don't make a difference between encoding scheme and transport protocol. Hopefully, I helped clarify this!
Slashdot Mirror
For those of you who are interested in what the patent applications are about but do not feel like sifting through them in search of actual information, I posted an analysis of the "Interdiction..." patent on the "Challenge of P2P" blog.
As an aside, and as discussed in the blog post to which I refer, what they characterize as hash spoofing does not require to break any cryptographic primitives. It merely refers to a form of false advertising.
Hmm. Actually, it does not seem to me that the reason why he is leaving is clear - at least, not from the article mentioned or from any of the comments that I've been able to read. JWZ left because he thought that Mozilla had been more a failure than a success (source: his web site) and did not have fun anymore working for a big corporation. At least, that's what I understood from what he said on the subject.
In some sense, the critiques that applied to Mozilla on April, 1st 99 (when jwz left) still more or less apply today: the product is not in a deliverable state. I mean, it's an alpha release, with various degrees of stability depending on the environment you're running it on, and that's definitely not a deliverable. Not yet, at least.
I don't contribute to the project by lack of time (insert your favorite excuse here) and because I'm not a good enough coder to participate in such a big project, where the code base is so huge and complex.
But I have a hard time understanding why Mozilla takes so long to take off when something like Linux or Free BSD, whose source code size is probably bigger than Mozilla's (correct me if I'm wrong), are still very active. It's definitely not the lack of people, or the lack of skills, but I'd like to understand where it comes from.
Complexity/messiness of the source? Communication problems? Lack of support from Netscape (that was one of JWZ's rants)? Or something else?
In short: what I get from this is that Open Source is not the solution to all of our problems. Sometimes, it doesn't work very well. At least, not as well as it could. And Mozilla seems to be an example of that, unfortunately.
Cheers,
No. Once you've got the codec, the rest is not very difficult to create (theoretically). You can basically rely on the usual transport protocols (that are in fact in the application layer), that is:
- RTP (Real Time Protocol) for the actual transport
- RTCP (Real Time Control Protocol) for controlling the bit-rate, and possibly do some dynamic adjustment of the encoding scheme
- RTSP (Real Time Streaming Protocol) which is a sort of "remote" control (it's sort of like HTTP/1.1 applied to a different context)
or ST-II for the old-timers, but I wouldn't advice itRTP, RTCP and RTSP's designs are not proprietary, and are described in RFC's 1112, 1889 (I've myself given a tutorial for a class on that, any interested parties can get the slides there).
They are used in the Real Players of all sorts.
As for the person who pointed out that Real doesn't scale well, I think it depends on what you call scaling. Typical implementations tend to be unicast, but people tend to switch to multicast (e.g., broadcast.com) which should scale better (less congestion). Unfortunately having scalable AND reliable multicast is still a topic of ongoing research.
Many people have been working on this since Deering's thesis in 86 (there is no Multicast TCP for obvious reasons), and so far, the results are so-so.
In short, the challenges are multi-fold:
This was redundant with some other posts, but it seems like most people don't make a difference between encoding scheme and transport protocol. Hopefully, I helped clarify this!
--Nick