Hal Finney wrote:
It sounds like the lack of documentation was a significant factor in
making the implementation difficult. Hopefully with the new draft this
will change.
It will certainly help. However I would stress that a simple, clear
protocol and formats architecture will make nice documentation easy.
The alternate, good documentation on top of a complicated protocol,
remains second best.
Maybe a more constructive approach is to ask whether the description
in the new draft is clear and useful. The draft is lengthy, yes,
but not very much of it is occupied discussing packet length headers,
and perhaps that portion could be made more concise. We could include
some code samples if this is an area where people are afraid of the
implementation difficulty.
Adding code fragments is a good idea. Code does not lie where text can
not help but spread mistruths.
Psuedo code or C or even Java would be very useful. We may even be able
to make this easier by adopting the convention that comments on the
draft, within this mailgroup, include code fragments to explain their
points, as Adam did earlier. Then, the editors can simply cut and past.
Oh, and when you say "where people are afraid," you are of course
referring to project leaders who are afraid of programmers who are not
afraid? This is the fear that I most often experience :-)
--
iang systemics.com
FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com