On Saturday 22 February 2003 08:56 pm, Ian Clarke wrote: > > So how about fixing up FCP so that it can handle the FEC/splitfiles > > just as automatically and transparently as fproxy? > > This was more-or-less the motivation for having different FCP "layers", > each providing a higher-level API. Unfortunately, it never really > happened.
I am planning on building a layer above the basic ezFCPlib primitives (open key, write key, close key) to do multi threaded scheduling among other things. Since it will be part of ezFCPlib, and compile on Windows and *nix (theoretically), it would serve as a useful addition to the C/C++ community. I am using the FEC-FCP extenstions for writing keys, but I plan on using the C code under Contrib/fecimpl/onion/alien/fec-1.0.3.zip for fcpget and related ezFCPlib logic. I (personally) think FCP does what it does well, and currently don't see any real need to add any major functionality. I agree with Gianni; "Adding an extra layer that allows client authors to make essentially unbounded demands on fred will not improve matters." -- Jay Oliveri "In the land of the blind, GnuPG ID: 0x5AA5DD54 the one-eyed man is king." FCPTools Maintainer www.sf.net/users/joliveri _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
