I try (again) to update my .NET FCP2 library to the current state of development.
I do not even expect that a rare Message is documented correctly, but something as essential as "PersistentGet" should be at least in a usable state, shouldnt it? A protocol should rarely change, especially a client protocol. But its in constant change and some of the messages even have dynamic parameters of course completley undocumented! If FCP shows anything of the development of the rest of the core, I am really happy I never looked at that code in deep! Anyway from the documentation: PersistentGet as an example Lists 3 Arguments which are not sent by the protocol anymore: /FileName/, /TempFilename/, /ClientToken/, not that any of these parameters are ever described, but even the message in the wiki is still the same since April 2010. And it doesnt help that you refer to the source code, source code is NO DOCUMENTATION! its really desastrous that you expose complete datastructures directly into the protocol, it makes it MUCH too easy to change the FCP, and it looks like there are a lot of people changing these strucutres constantly. In the meanwhile there are obviously 5 new undocumented fields in it.... /Started/, /Persistence/, /MaxSize/, /Identifier/, /Binary Blob/: most of these are now documented at least in the Call, and the removal of the ClientToken is certainly a good idea HOWEVER!!! ITS NOT DOCUMENTED!... In the ClientGet-Documentation there is still the field "ClientToken" described as Returned in PersistentGet <http://new-wiki.freenetproject.org/FCPv2/PersistentGet>, a hint to the client, so the client doesn't need to maintain its own state. [FIXME: how does this differ from Identifier?] ... You change the protocol permanently but have not even the time to send a message back, OH I am sorry, I do not understand that parameter, maybe its out of date? There needs to be a versioning of the protocol, its impossible to keep track of all the source changes you do, and you should not expose datastructures directly to the client interface, this is a very poor design and makes impossible to support FCP2. This is not FCP2 this is at least FCP2.0.174 There need to be a review process, if you change the protocol - there must be a reason for that and not just conveniance, and the reason needs documentation. If you change anything in the FCP it should get a new protocol number and any change needs to be documented. If you do not invest 10 - 20% of development time for documentation, you do something wrong! There is too much development going on and not enough planning documenting, hack something together, deploy and use all the users as testers... I won't get into general Project Planning - if there is one, but the FCP is a reference for the outside, and it shows mainly incomeptence in a great degree. The main page still links to the old wiki, the new wiki is not used at all, there is not a single wiki-commit for the fcp in the last 30 days. Regards, Thomas Bruderer, Apophis -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110605/22450fdd/attachment.html>
