logo_kerberos.gif

Difference between revisions of "Projects/Kerberos Documentation"

From K5Wiki
Jump to: navigation, search
m (Updated "Documentation for application developers" with the link to the "Differences between Heimdal and MIT Kerberos API".)
m
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
{{project-early}}
 +
{{project-rel|1.11}}
   
 
== Purpose ==
  
== Purpose ==
   
 
The goal of the project is to create an infrastructure and process for the future development of the extensive Kerberos documentation.
  
The goal of the project is to create an infrastructure and process for the future development of the extensive Kerberos documentation.
  +
The documentation should be useful and correct; it must be detailed, but optimized -- do not be too verbose.
   
 
'''The documentation will be built incrementally. We will analyze what works and what doesn't and correct the course of action as needed.'''
  
'''The documentation will be built incrementally. We will analyze what works and what doesn't and correct the course of action as needed.'''
  +
Part of the criteria for "what works" is that the documentation should be easy to maintain.
   
 
The actualized documentation will be useful for developers and administrators, both for experienced ones and newcomers. It will address the following topics:
  
The actualized documentation will be useful for developers and administrators, both for experienced ones and newcomers. It will address the following topics:
Line 13: Line 15:
 
* Cookbook for administrators - Installation, configuration, troubleshooting.
  
* Cookbook for administrators - Installation, configuration, troubleshooting.
   
−  
−
== Example ==
  
−  
−
Please, follow this link for Kerberos documentation general example [http://web.mit.edu/tsitkova/www/build/index.html];
  
−
advanced admin topic example: [http://web.mit.edu/tsitkova/www/build/cookbook/advanced/ldapbackend.html]
  
−
MIT Kerberos features: [http://web.mit.edu/tsitkova/www/build/mitK5features.html]
  
   
 
== Documentation for application developers ==
  
== Documentation for application developers ==
   
−
TODO
  
  ⚫
Generally any topic in the Kerberos documentation can cross-reference with function documentation and each other.
−  
⚫
Generally any topic in the Kerberos documentation can cross-reference with function documentation and each other. See [http://web.mit.edu/tsitkova/www/build/tutorial/h5l_mit_apidiff.html]
  
   
   
Line 31: Line 25:
   
   
−
==== Documenting functions ====
 +
=== Documenting functions ===
−  
−  
−
=====Part_1=====
  
−  
   
 
The following fields ''must'' be included in the function documentation and should reside in the source code :
  
The following fields ''must'' be included in the function documentation and should reside in the source code :
Line 40: Line 34:
 
# Return value description
  
# Return value description
 
# Detailed description (optional)
  
# Detailed description (optional)
−  
−  
−
One can see that Part_1 contains the information that is the most useful for those who update the code and fix the bugs. To avoid the code overcrowding and make any additions to the function documentation as simple as possible, we suggest to save additional documentation ( see below Part_2) in the separate location - one file per function..
 
−  
−
Effectively this means that we expect the Doxygen style comments in the headers in the following format:
  
−  
−
<pre>
  
−
/**
  
−
* @brief Some brief description
  
−
*
 
−
* Optional detailed description
 
−
*
 
−
* @param[in] arg1 Description of arg1
  
−
*
  
−
* @return Something useful
  
−
*/
  
−
char * KRB5_CALLCONV
 
−
krb5_X(type arg1)
 
−
</pre>
  
−  
−
Note, that ''@brief'' notation may be omitted if JAVADOC_AUTOBRIEF is set to YES in the Doxygen configuration file. In this case the very first line of the comments will be interpreted as the brief description:
  
   
 
<pre>
  
<pre>
Line 74: Line 47:
 
krb5_X(type arg1)
 
krb5_X(type arg1)
 
</pre>
  
</pre>
−  
−  
⚫
=====Part_2=====
  
−  
   
 
The ''optional'' fields may include:
  
The ''optional'' fields may include:
Line 89: Line 58:
   
   
−
''' Part_2 in ReST format '''
  
  ⚫
==== Workflow ====
−  
−
When available, we suggest to have Part_2 information associated with the particular function in ReST format. For example:
  
−  
−
* Warnings and suggestions
  
−
Warn about any potential mistakes and misuse.
  
−
Point to other useful routines.
  
−  
−
* Links to RFC, wiki Projects, krbdev discussions
  
−
:rfc:4120
 
−
Or if you want to reffer to the specific section of the RFC use the following notation: :rfc:4120#section-5.2
  
−
Or link to Kerberos Project page, for example, Disable_DES project <http://k5wiki.kerberos.org/wiki/Projects/Disable_DES>
  
−  
−
* Example
  
−
The place for the function usage examples
  
−  
−  
−
''' Part_2 in Doxygen format '''
  
−  
−  
−
Alternatively, when desired, Part_2 may be documented in Doxygen format by adding ''@include'' directive to the comment, for example, to reference to example code fragments
  
−  
−
<pre>
  
−
/** Some brief description
  
−
*
 
−
* Optional detailed description
 
−
*
 
−
* @param[in] arg1 Description of arg1
  
−
*
  
−
* @return Something useful
  
−
*
  
−
* @include example_krb5_X.c
  
−
*/
  
−
char * KRB5_CALLCONV
 
−
krb5_X(type arg1)
 
−
</pre>
  
−  
−  
−
Note: The path to the example file (here example_krb5_X.c) must be set in the EXAMPLE_PATH tag in the Doxygen configuration file
  
−  
−  
−
=====Workflow: Putting Part_1 and Part_2 together=====
  
−  
   
 
# Configure Doxygen to generate output both in xml and html formats. Run Doxygen.
  
# Configure Doxygen to generate output both in xml and html formats. Run Doxygen.
−
# For each function and data type generate document in ReST format. It is expected that it contains information from Part_1. For the function ''krb5_X()'' lets call it ''krb5_X_p1''.
 +
# For each function and data type generate document in ReST format. For the function ''krb5_X()'' lets call it ''krb5_X_p1''.
−
# (For ReST format only) If the Part_2 documentation for ''krb5_X()'' has been already written, there is a file called ''krb5_X_p2.rst'' in the designated directory. If not - nothing happens.
  
−
# (For ReST format only) Concatenate ''krb5_X_p1'' and ''krb5_X_p2.rst'' (if it exists), add the link to Doxygen generated documentation for this function in html format (generated automatically) and save as a file ''krb5_X.rst''.
 
 
# File ''krb5_X.rst'' can be used as input for Sphinx
 
# File ''krb5_X.rst'' can be used as input for Sphinx
−  
−
NOTE: Initially we provide Python script to automate steps 2-4. The whole process will be automated later.
  
−  
−  
   
   
−
==== Documenting data types ====
 +
=== Documenting data types and macros===
   
−
TODO
  
  +
Similar to documenting functions.
   
   

Latest revision as of 10:21, 29 October 2013

This project was completed in release 1.11.


Purpose

The goal of the project is to create an infrastructure and process for the future development of the extensive Kerberos documentation. The documentation should be useful and correct; it must be detailed, but optimized -- do not be too verbose.

The documentation will be built incrementally. We will analyze what works and what doesn't and correct the course of action as needed. Part of the criteria for "what works" is that the documentation should be easy to maintain.

The actualized documentation will be useful for developers and administrators, both for experienced ones and newcomers. It will address the following topics:

  • Complete reference - API, internal functions, data types, macros
  • Tutorial for application developers - description on various tasks such as working with credentials, topics on how to write plugins, etc
  • Cookbook for administrators - Installation, configuration, troubleshooting.


Documentation for application developers

Generally any topic in the Kerberos documentation can cross-reference with function documentation and each other.


Details of source documentation

Documenting functions

The following fields must be included in the function documentation and should reside in the source code  :

  1. Function signature
  2. Brief function description
  3. Arguments - [in/out] with description
  4. Return value description
  5. Detailed description (optional)
/** Some brief description
 * 
 * Optional  detailed description 
 * 
 * @param[in]  arg1  Description of arg1
 *
 * @return Something useful
 */
char * KRB5_CALLCONV 
krb5_X(type arg1)

The optional fields may include:

  1. See also section to refer to the related functions,
  2. Note section to highlight the specifics of the behaivor
  3. Examples of the usage
  4. Snap-shot of the real code involving this function
  5. Links to KRB5 Wiki Project page, krbdev discussion, RFC document or its section etc
  6. Version of Kerberos when fuction was introduced or became obsolete


Workflow

  1. Configure Doxygen to generate output both in xml and html formats. Run Doxygen.
  2. For each function and data type generate document in ReST format. For the function krb5_X() lets call it krb5_X_p1.
  3. File krb5_X.rst can be used as input for Sphinx


Documenting data types and macros

Similar to documenting functions.


How to contribute

  1. The core team - the administrator - posts the initial list of the tasks (such as API, admin tasks, "How to"-s etc) and further supports it. See Projects/Documentation Tasks for more detailed information.
  2. Community can suggest new tasks
  3. The core team provides templates that, if helpful, may be used by the documentation writers. The most desirable format for the contributed documents is ReST as the easiest to integrate with the mainstream documentation.
  4. Community can provide the feedback on the documented tasks.

Tools

Retrieved from "https://k5wiki.kerberos.org./wiki?title=Projects/Kerberos_Documentation&oldid=5245"