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
_______________________________________________
Devl mailing list
[email protected]
http://freenetproject.org/cgi-bin/mailman/listinfo/devl
