> My Java sux totally, since I've only been dabbling in it for a few weeks and > then, not seriously studying it.
Java is very, very easy if you know C++. > Seriously though - I'll have a look, but I'm a bit sceptical about the > feasibility ot getting the required speed in a Java FProxy implementation. C++ coders have a natural and incorrect feeling that Java is too slow. I don't think it will be a problem. > Maybe some hard-assed coding decisions might result in being able to stream > MP3s (on a fine day, with the tongue angled 15 degress upward out the left > of the mouth, and no other processes running), but then again, maybe not. As > for MPEG streaming, I don't hold much hope. I stream MP3s from FProxy regularly. MPEG streaming is impossible to the speed of the *network*. > Again, I propose, what do people think of a portable C (yeh - straight C) > FProxy implementation? I think that's a really terrible idea. First of all, I see no burning problem with the current speed of the code which necessitates a rewrite. Second, C networking code is not portable. You could of course write some code with ifdefs which would compile and run on Windows, Mac, and several Unices, but I think that will be difficult to maintain. Rewriting stuff in C should only be done with good reason, but the current complaints about FProxy are just about some bugs it has. > A native binary FProxy will stream MPEGs easily (constrained only by the > speed of data flow into the node). The network is too slow to stream MPEGs. _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
