Richard, May I recommend the skeleton appendix in the RFC draft along with the main text and flow diagrams. More detailed diagrams are in the UDel report cited in the RFC. I took great care in commenting the protocol and crypto source code, expecially since some of my code is fifteen years old and I might not remember why I did what I did.
There would be considerable value in a utility that could parse the makefiles, identify the build sources and header files, then make an index showing where each external variable is referenced. I did that manually for the code skeletoon, but that's not the real article. Dave Richard B. Gilbert wrote: > Harlan Stenn wrote: > >>>>> In article >>>>> <[EMAIL PROTECTED]>, >>>>> [EMAIL PROTECTED] (Prathapnirmal) writes: >>>> >>>> >> >> prathapnirmal> Hi All, Which will be the best document to refer if I >> need to >> prathapnirmal> know information about the organization of code in ntp? >> >> And the answer is... >> >> prathapnirmal> One obvious way is to look at the makefile.am in >> prathapnirmal> each directory to figure out what is made out of what. >> >> That is the definitive answer. >> >> prathapnirmal> ... I will put it across to everyone to see if there is >> prathapnirmal> any documentation related to this. Also is there a >> design doc >> prathapnirmal> that talks about this or other details? >> >> There really isn't anything else. >> >> The "market" for such a document seems to be small, and then there is the >> issue of who would maintain it. Now, if somebody were to volunteer to >> write >> and maintain such a document I'd be happy to put it in the distribution. >> >> Would such a document really be all that useful? It seems to me that the >> codebase is pretty small, and it should not be all that hard to figure >> out. >> > > I had my computer count the lines of code in one of the older versions, > about two years ago. 70,000 or so lines of code may be a small number > to you but it seems like a lot to me. I once looked at the code for the > Motorola Oncore driver to try to understand what was going on and failed. > > It's never easy to wrap your mind around someone else's code, especially > when there's that much of it. It's even tougher if you're not really > fluent in C. I can struggle though it but I'm not what you'd call fluent. > > Rather than writing a separate document, I'd recommend carefully > commenting the code itself. This would include identifying what the > variables and data structures represent, and cross referencing the code > to the RFC. I'm not going to hold my breath though. Most programmers > would rather write code than documentation. > _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
