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]>
===========
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
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
