I fear that you might be providing a nice strawman with which people can argue against my proposal ;-)
Ian. On Wed, May 16, 2001 at 01:01:44PM +1200, David McNab wrote: > 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
