Hi David: SplitFile encoding/decoding/insertion/retrieval are extremely resource intensive operations (memory, CPU, threads, temp space). The decisions about how to make the relevant resource usage tradeoffs belongs in the application code. Not in FCP.
Fred barely works as it is. Adding an extra layer that allows client authors to make essentially unbounded demands on fred will not improve matters. I agree that client developers deserve as much support as we can give them. You could do the community a great service by writing and publishing a good FCP/FEC client library in Python. Regards, --gj David McNab wrote: > Hi, > > While FCP is comfortable for most things, it's painfully low-level when > it comes to FEC/splitfiles. > > The logic for FEC/splitfiles is already in Fred, because FProxy uses it. > > So how about fixing up FCP so that it can handle the FEC/splitfiles just > as automatically and transparently as fproxy? > > I'd rather use Python http methods to insert/retrieve via fproxy, than > figure out all the grotty details of FEC/splitfiles and handle that in > my client classes. > > If people don't like the idea of putting transparent automatic > FEC/splitfile handling into FCP, then I'll go the http->fproxy route. > > How about it, guys? Doncha think FCP could be a little more high-level? > > Do you think that Freenet client programmers deserve a bit more support > at the interface level? > > Believe me - the more approachable the interfaces, such as FCP, are, the > more client programmers you'll attract, and the more popular Freenet > will become. In other words, success. > > Cheers > David > > _______________________________________________ > devl mailing list > [EMAIL PROTECTED] > http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
