diff -r 000000000000 -r 6474c204b198 layout/doc/dd-template.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/layout/doc/dd-template.html Wed Dec 31 06:09:35 2014 +0100 @@ -0,0 +1,116 @@ + + + + + + + + Layout Detailed Design Template + + + + +

Gecko Layout Detailed Design Document Template

+ [Use this template to start your detailed design. Replace items in square + brackets with the appropriate text for your component, class or system.  Keep + in mind that this is just a general template intended for most designs. +Your specific design may require different organization or topics - the +goal is to provide detailed information about the software to the reader.]
+
+ +

[Component / Class Name] Detailed Design

+ +

Overview

+ [Introduce the scope of this design document: what is being documented here. +Provide a reference back to the High Level design(s) that correspond.]
+ +
+

[Class / Component A]

+ [Briefly refresh the reader with the purpose of the class or component. +Provide enough information to make accessible the following sections on the +public API, private methods and members, and algorithms. Bring up and tricky +or otherwise interesting relationships that will be detailed.]
+
+ +

Public API

+ [Show the public API for the component, as IDL, C++ header file, or as a +pseudo-code description.  If using a source file, the comments in the +source file should cover most of the detail needed. If they do not, then add +that detail there.  See the Overview document for more details on the +scope of information that should be presented.]
+ +

Protected API

+ [If there is a protected API, list the methods and members and indicate +the responsibilities of the callers with respect o calling the base class, +enforcing base class invariants, etc.]
+
+ +

Implementation Notes

+ [The nasty details of the implementation get exposed here. This section +can be broken down into subsections as necessary, and should include details +of particularly important algorithms, performance characteristics or constraints, +memory usage, tricky ownership issues, and anything else that would make understanding +the implementation easier for the reader.]
+ +

Algorithms

+ +
[Interesting Algorithm 1: The internally maintained sorted list]
+ [explain the nature of the algorithm, the reason it was chosen, the types +of input it is expected to operate on, etc. Annotated pseudo-code is a good +idea here, but actual code is often too detailed to b of much use by itself. +It the actual code is sufficient to understand it, then this subsection is +probably not needed.]
+ +
[Interesting Algorithm 2: Handling overflow of the input buffer]
+ [your description here]
+ +

+ +
+

[Class / Component B]

+ [Repeat the structure for the next class or component.]
+
+ +
+

Cross-Component Algorithms

+ [specify the details of algorithms that cross a single component. refer +to each component, describe the flow of control, the responsibilities of each +component along the way, the error handling, the state-management if any, +and the expected results for a given input. Generally each of these algorithms +gets its own subsection.]
+ +

[Turning a byte-stream into a fully parsed token-tree]

+ [Detailed description, pesudo-code, state transitions, etc.]
+ +

[Managing updates to the document]

+ [Detailed description, pesudo-code, state transitions, etc.]
+
+ +
+

Tech Notes

+ [This section contains links to tech notes related to the implementations +covered in this design.  Tech Notes tend to be extremely specific, often +recipes for how to do something or how to fix a class of defects.  If +the tech note is more general, it may be a good idea to move it into the Detailed +design itself.]
+ + +
+ + +