I wanted to update my FCP2 Library this week, and since I was aware of the ever changing defintiions ins Freenet, I already made up code for easily detecting the changes in the Protocol directly out of the library. Its very difficult to keep an OO Wrapper consistent to a documentation when the documentation is just horrible.
Its not a problem of the documenter, Actually its indeed pretty well documented if you see the amount of documentation needed. There are 33 Calls and 40 Callbacks with even more parameters and values to document. This is insane! One of the most wicked calls is GetNodeData which returns a huge list of information. The data is hopelessly outdated. The link to github: http://github.com/freenet/fred-staging/blob/master/src/freenet/node/fcp/NodeData.java is completly useless since all the fields are defined in different methods. FCP2 should be the interface for the developers not directly involved into the core of the project, but to really write a FCP2 compliant Client its nearly impossbile to do without having a sourcecopy of Freenet. At the moment there dozens of undocumented fields. Meaning there are not even mentioned! And then there are this very strange "dynamic fields" they pop up and go --- depending of the state of the Node. Thats inaccaptable that Parameters can pop out of nowhere... I have a nice example out of the NodeData event. volatile.numberWithRoutingBackoffReasons.InsertTimeoutNoFinalAck (System.Int32 = 1) volatile.numberWithRoutingBackoffReasons.TransferFailedInsert (System.Int32 = 1) volatile.numberWithRoutingBackoffReasons.TransferFailedRequest13 (System.Int32 = 2) volatile.numberWithRoutingBackoffReasons.TransferFailedRequest14 (System.Int32 = 1) volatile.numberWithRoutingBackoffReasons.ForwardRejectedOverload (System.Int32 = 16) volatile.numberWithRoutingBackoffReasons.ForwardRejectedOverload5 (System.Int32 = 1) You see? There are TransferFailedRequest13 and TransferFailedRequest14 ... what the heck? But these fields can disappear completlly at times, with or without a strange index number. Such a difficult and complex protocol needs a clean computer readable definition. Then you can write a Protocol compiler and you are sure you are talking the same language as the node. But at the moment its impossible to write a completly FCP2 compliant client. I'll fix the most obvious things and add the methods which are documented, but I cannot expose the whole functionality at the moment.
