> > I would say that implementing streaming over discrete finite fetches is > more messy and complicated than adding a little to support streaming.
More messy for the client, less for the server. Servers need to be simple and efficient. Cleints can be as complicated as needed and not affect the efficiency of the system as a whole. > We should make a generalized protocol which can handle either... As in life, the more things you try to do, the worse you are at all of them. Unix tools and network protocols have benefited pretty well from the "do one thing well" philosophy. Sure, there's also Perl, which has benefited from the exact opposite. Sometimes it's hard to tell which is more appropriate for which project, but I'm inclined at the very least to say let's get Freenet working first--at least doing one thing well--then maybe add stuff like streaming or multicast or broadcast searches one at a time to see what breaks. > Doing streaming data with discrete fetches is a bad idea because then you > have 2 messages per unit instead of 2 messages for the entire transaction. You know as well as I do that's a specious argument. The overhead of a message is insignificant compared to the payload of any decent-sized data, and if you're considering streaming, your data is so large that it is completely insignificant. Not to mention the fact that the messages requesting the second chunk can all happen parallel to the transmission of the first, so the overhead can be exactly zero. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lcrocker.html> "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
