> Dare I even form the notion, let alone express it, that FCP really needs to > present an interface at least as high-level as the existing command line > clients, fproxy and freenetmirror/getfiles/putfiles.
Guess I should explain better. I am *not* suggesting in any way that FCP should implement FProxy. What I *do* mean is that I personally would like it if FCP allowed keys to be treated as 'black boxes' with the same simplicity and high-level treatment as with FProxy, and the command-line clients. In other words, you request a key, and FProxy does all the metadata handling in the background, and delivers the final file. As does freenet_request (unless '-autoRedirect no' is set). Perhaps I should have said it simpler, that it would be nice if FCP provided some high level commands to support automatic metadata generation and inserting, for example: ClientRedirect HopsToLive=<htl> SourceURI=<URI to be created> TargetURI=<URI of existing key to redirect to> EndMessage Sorry about the confusion Cheers David ----- Original Message ----- From: "David McNab" <[email protected]> To: <devl at freenetproject.org> Sent: Wednesday, May 16, 2001 1:01 PM Subject: Re: [freenet-devl] FCP Layer #2 and beyond... > Hear hear, Ian!! > > It's bad enough that I've had to write metadata handling into my FCP client > library, but being asked to calculate public key suffixes using base-64 > arithmetic takes the cake! I'd be willing to do that if I had to, I'm not a > complete technical moron, but it pisses me off thinking about the 'teeming > hordes' of prospective client writers all implementing n versions of the > same functionality. > > I'll say something here which I know will incur scorn and disrespect, but > what the fuck! ... > > IMO, clients should be able to use Freenet keys as 'black boxes' without > knowing their inner structure or meaning. Blasphemy? Maybe. > > Dare I even form the notion, let alone express it, that FCP really needs to > present an interface at least as high-level as the existing command line > clients, fproxy and freenetmirror/getfiles/putfiles. > > As for FCP layer 2 - more is needed here than merely a 'HandleMetadata' > field on requests. If FCP is to really implement layer 2, it'll need to > support insertion with simple mechanisms for metadata creation - straight > redirect, date-based redirect, mapfile manifest insertion and splitfiles > would be a very desirable minimum. > > Yes, it's more work for in-Freenet developers, but the payoffs will be vast. > Remember, such 'extra work' only needs to be done *once* ! > > Client writers will feel more supported by Freenet, and in turn, will > contribute immense creativity and functionality which will deliver Freenet > into mass acceptance, and **genuine fulfilment of its mission**. > Imagine freeware/shareware sites with whole sections devoted to the hundreds > of successful Freenet clients :) > > Cheers > David > > > From: "Ian Clarke" <ian at hawk.freenetproject.org> > > =========== > On the subject of layer #2, the only addition that I can see which needs > to be made to FCP is the addition of an optional "HandleMetadata" field > to ClientGet (which, if set to "yes" will handle metadata > transparently). > > Layer #3 will involve some completely different commands. > > I know that some people think that layers #2 and #3 should be > implemented by client writers, however this has the following > disadvantages: > > * It makes more work for client writers, discouraging them from writing > clients (exactly the opposite of the intention of FCP) > * It increases the likelihood of buggy metadata implementations, which > could go unnoticed if clients eat their own dogfood successfully, but > not other people's > > Contrary to some people's beliefs, I don't think that FCP should be a > minimal implementation, if that was the intention then it should have > been a compact binary protocol, and shouldn't have all the key > generation stuff (which could be handled by client libraries). On a > more practical level for FCP advocates, XML-RPC will be incorporating > metadata handling, and stacks support. Which do you suppose will be the > choice of client writers if FCP tries to take the "purist" route? ;-) > > For those who think that layer #2 should be a front-end to layer #1, all > you are doing is adding unnescessary bloat. Any smart implementation of > layer #2 will interface directly with the node, and there will be no > incentive to use layer #1. > > We have started down the path of creating a *useful* API, we definitely > shouldn't stop now. > > Ian. > =========== > > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://lists.freenetproject.org/mailman/listinfo/devl > _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
