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.
PGP signature
