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" <[email protected]> ===========
